We chat with Mike Brevoort, Platform Architect at Slack, about the power of platforms and what developers can do to automate workflows and processes that used to be shared across multiple teams, but now often fall to individuals working remotely and asynchronously.
You can check out our piece how developers can be their own operations department here.
Our piece on preventing scope creep while working from home is here.
You can follow Mike on Twitter here and learn more about building apps for Slack here.
This week's lifeboat badge goes to averroes for helping us to : Check if integer == null
Mike Brevoort And so there are teams that are like hyper focused on certain aspects of the product of one, trying to improve them and two, not ruining them. Because I think you know, when you're successful and have a successful product, you're more likely to ruin it than you are to make it better, in a lot of cases.
[outro music]
Ben Popper CockroachDB is the only bug you'll ever love. Because it's the only one you don't have to worry about, as a low touch SQL database that automatically handles scale operations and uptime, CockroachDB lets you focus on developing. Get your free cluster and a free t shirt at cockroachlabs.com/stackoverflow.
BP Hey, everybody, welcome to the Stack Overflow Podcast, things to talk about—a place to talk about software, technology, the future of work. I am Ben Popper, Director of Content here at Stack Overflow. And I'm here with my co-host, Paul Ford. Hi, Paul!
Paul Ford Hello, Ben. I know we're mixing them in, so Sara, this is a post-Sara episode.
BP This is a post-Sara episode. And in fact, if we brought on a fresh Stacker out of the trenches, my colleague Ryan Donovan is here today.
PF Ryan!
BP Hi, Ryan.
Ryan Donavan Hey guys, how you doing? How you doing?
BP For people who don't know, Ryan graduated from CMU with a degree in technical writing, was working at The Grubhub blog and then came over to work on my team about a year and a half ago. He's been doing a great job for us. Basically running, running the blog, pulling in all the pitches, deciding what goes up editing the stuff that's too technical for me. And Ryan also helps to get our newsletter out every week. So a big part of the content marketing editorial operations here at Stack Overflow.
RD Right. Very flattering introduction. Thank you.
BP You're welcome. So Ryan, I know we have two blog posts that we were hoping to publish this week. Can you sort of queue those up for us? What was the pitch? And what are we going to put out there? And once we get that, we're going to bring on a great guest and sort of walk us through some of these ideas.
RD Sure. The the two posts we've been talking about, there's how developers can be their own operations department. I found that one from a comment ib another piece, I thought it was sort of a interesting counterfactual, you know, everybody is, you know, building up their DevOps departments. And I wanted to sort of see how that was done. Get some discussion on it. The other one is, how to deal with scope creep, when you're working from home. Sort of an interesting idea that scope creep, you know, we all face it. It can be worse when you're working from home, you don't have this sort of, you know, firewalls stop gaps that you do, right and your person.
BP Okay, cool. Yeah, I like that first one. Paul, I was just listening to the podcast with the folks from Netlify, I think one of things you said was when everyone is DevOps, no one is DevOps.
PF My co-founder is doing a side project at at Postlight. Just something, we like to keep our skills fresh, even though we're corporate leaders watching him because I've done the same path, like watching him figure out how to deploy a relatively simple but still not totally static website. And watching just like the brains pour out of his ears, as he—my take, I'll give you my take, because, you know, this isn't what this podcast is about. But as we've been talking about it, because I'm like, well, you know, Google Cloud run is really good over here. And he's like, yeah, but Heroku. But Heroku blows away your, your storage every night, so I can't use SQL lite, and sort of, on and on. And what's happened with DevOps is they've abstracted out the whole Unix machine into all these little tiny components. But the thing is, that thing built itself over 30 years that like a nice Linux platform to be a really good hosting environment. And so sometimes you just want a little box running somewhere with a configuration file in a web server on it, to do the work for you. And then instead, you have to learn, you have to go to AWS, and there's all those little tiny Lego pieces, and you're literally putting Unix back together, which only really works if your scale is like, you know, like Walmart scale. Not that Walmart should be on AWS, that'd be really confusing for everybody. That's capitalism gone wrong. But anyway, that's all I just want to make that little point so that people at home have a point about DevOps at that they can internalize.
BP I mean AWS is the big box store of cloud platforms for sure.
PF Exactly.
BP You go in and you just get lost wandering down the aisles. And when you leave, you have 10 times more stuff than you need.
PF But it's just one server turned into millions of icons, you could also just get a Raspberry Pi and probably host 90% of the things you're ready to host. Anyway, that's just one person's opinion about DevOps.
BP So we have a great guest coming on today, actually to talk about all this Mike Brevoort, who is a Senior Engineer at Slack and has a lot of thoughts about sort of the workspace that people are crafting at home. Mike, welcome to the show.
MB Thanks. Thanks for having me!
BP So Mike, tell us a little bit about who you are and how you ended up at Slack. I know you had a company of your own and this was through an acquisition maybe?
MD Sure. Yeah. So I joined Slack almost three years ago. Currently platform architect leading sort of the next generation of our platform, I joined through an acquisition of a company I built called Missions, which was a messaging based workflow system that aim to try to reinvent workflow on top of these messaging platforms like Slack. And then before that did a bunch of stuff, and I'm getting old. [Ben laughs]
PF Isn't that the best? Isn't that fantastic? Especially in this industry, an industry that just loves people getting older? Oh, hold on. Alright, first of all, what is a platform? Let's get someone who builds platform to tell us what a platform is.
BP Oh gosh, come on, Paul. Not fair. Go ahead, Mike.
MB Yeah, I mean, this is probably an unfair question. But I think, you know, when it comes to platforms as part of products, I think the most important part of a platform is that you enable people to build greater value than the product to create on its own. And so whether that's money, so you allow people to build businesses on the platform, like I did, so I built before I joined Slack actually built a business on the platform, right, or value in general. So the platform is all about value creation and inclusivity.
PF There's another element too, which I always think about, which I think is a very, this was very much like Microsoft's way of thinking about it, which was that you're always the transaction costs go down to as the platform scales, like bigger gets cheaper and easier as time goes on.
MB And similar to what you were talking about with, you know, AWS, you're just like, it's like layers that you stand on, it's like standing on the shoulders of giants. And these platforms are places to stand upon, to build upon. So you don't have to build, you know, your Unix server all on yourself, you get to plug into a platform, like a platform like Slack that provides things like, you know, push notifications, and messaging and authorization, and basically authentication and a UI framework and all these little bits to be able to connect to build on top of and reach I think like network reach to people, customers opportunities, especially when they're the customers, the people that you want to reach is a big opportunity in a platform.
RD And it doesn't hurt that they're becoming dependent on your platform, right, they're building their lives on your platform.
MB I mean, it really shouldn't be your goal, I think anybody that has that goal will find themselves in probably a dark place way down the road. Like we don't want to trap anybody to use our platform. If you find it valuable, you'll stay you'll bring other people. And you'll build on it. And I think that you know is like that rising tide sort of raises all boats mentality.
PF Well, here's what's tricky with that, right, which is, and this is the complex thing about enterprise. And I work in this space to just in a much really tiny way compared to the scale of Slack, which is that a lot of your users are given this thing when they walk in the door, right? And they they're just sort of like, okay, you're on Slack now. And I think, look, it's a baseline, everybody uses it. And I like I can't imagine my company without it. But how do you think about that, right? Like a lot of the people who are coming in, and I think almost tie it back to, you know, workflow is such a broad, and it's almost as spongy as platform, and I really liked your definition of platform. When you're talking about workflow, what are you talking about? And like, what does that mean to the people who, you know, "here you go, welcome to the company, here's your Slack login, let's get some work done."
MB You know, I think it really just comes down to how your team works, and how you get things done, how you work together, the tools and the processes that you use. And I think of workflow. It's not the 25 step automation, that generally is pretty brittle. It's all the little things, is what we tend to call the work of work and all that you could automate those little bits. That's what I consider workflow, like really simple. And it's why we built that Missions product in the first place. That's why we're doubling down on workflows at Slack, is that you know, simple things like filling out a form and routing that to someone to be able to make a decision to be able to draw a certain person or teams attention to certain things at a time. Like we consider that workflow. It's really like how workflows within the system of people's and the tools that you use, and—
PF Just real quick go from abstract to concrete, like give me an example of a task getting done with inside of a workflow context?
MB You know, we have a there's a lot of cases at Slack, where we use shared channels with, with all of our customers, there's a term called Slack Connect, we can connect multiple companies. And it's really common to create a workflow and there's channels for people to submit feedback or request a meeting with their, their, their corresponding person on the Slack side, or vice versa with those teams. And you could have posted in that channel a message to say, "hey, I'd really like to meet talk about this." And then you would wait for someone to respond and say, when might we do that when you were available? And what do you want to talk about? And who might we need to bring the conversation and instead if you if you front door that with a form that asks for exactly what you need to be able to service their request, and they know what they need to provide and you can react to it very quickly. Like that's just like this grease between the cogs to streamline who needs what when and how can I service them as soon as possible?
RD I think it's interesting that Slack has sort of become the default notification channel. It's sort of minimized the places where you're getting notifications right? Like you get email, you got your JIRA, you got your other apps and they all go to Slack.
BP Google Docs. Monday.com. Do you want me to go on? I could go on for hours.
PF Well, literally, so can YouTube advertising. So can literally everything. [Ben & Ryan laugh]
RD Yeah. And they all show up in Slack. And it makes it a sort of simpler workflow.
BP I think also well, just to say, I mean, it is really interesting because like, there's friction within even one organization, how do we organize things? When you're trying to mesh to organizations in that shared channel, you're really, like you said, overcoming a lot of hidden obstacles in the sense of, oh, maybe we could book a meeting, but we're not on the same calendar. And I don't have your email. And you know, there's just like, a lot of unknown unknowns there that you can sort of, yeah, avoid that friction if you build these automations.
PF So I have a tiny Slack story, which is relevant. And then I want to ask a question. So my tiny slack stories one day I was complaining, because I'm old, that it's very hard to see emojis or Slack emojis at their little tiny size. My worn out eyeballs can't witness them. And I tweeted about this. And Stewart Butterfield endorsed the tweet, which is not a great thing. If you're, I mean, like, it's, it's an awkward moment, right? Because it's just like, I guess this has to be dealt with now. I'm assuming if you're on the inside of Slack. And then later, much later, which was a wonderful insight into how long it takes to change product at a certain scale. That happened. It was really good and really exciting. And now when you mouse over, you see the emojis and I'm sure that was not only my idea, I'm sure that's Stewart was just having a good time with me. So let me take that back and issue another feature request now that I have another Slack person nearby. [Mike laughs] And the reason I'm doing this is actually, I'd love to talk about how getting something into—Slack is huge. And it's possibly assuming the deal goes through part of an even bigger organization in Salesforce. And so like, I'd love to talk about how ideas get into products at this scale, because I think relatively few people have that experience, who are listening, And you're someone who does that all day. And so here's my feature request, I would like a random like, just when you go into Slack, and it gives you that nice random channel, right? Where everybody can chat. I would like a version of that, that expires in like, two hours. Right now, Slack only lets me expire things, I think in 24 hour intervals. I'd like something that's truly disposable, truly random, so that people can kind of just chat but not feel that like when somebody comes in later and does a search or connects that they're going to be able to find this stuff, because that's actually as my company scaling, people are coming in from other organizations or people are coming in connected to other things. And we're worried that like they're going to search for the products they worked on and find us complaining about them. And so like, that's my feature request. Okay, first of all, how would I make that? How would I actually say—
RD You want a 4chan Snapchat version of it?
PF Yeah, we actually built one at work. It's called yap.chat, which is just ephemeral chat. But it's that's nothing compared to what it would be like if it was built into Slack.
BP Ryan, I thought you were saying, if you want to get Stewart's attention on you have to go on 4chan? I was very—
PF Noooo, no, no, no. Wooooo boy. That would be a hell of a Daily Beast story.
BP Mike, yeah, let's say let's say you wanted to, yeah, you know, float a product idea and get it on the roadmap and have it become a reality down the line, what's a good place to start in that sort of, yeah, like amorphous space of a big co.
MB It's a you know, it's a challenge. It's like a challenge, even whether it's your personal life, professional life, whatever role you're in, there's so many demands, drawing your attention that you could only read one thing at a time, think about one thing at a time. And you've got to try to take in all this information, synthesize it, and make sense of it and figure out what's important, and to who and how does it drive, you know, the type of change that you're trying to make. With your specific example, that's a really good example of a case where you could build an app for Slack on a platform that has an admin token that is a member of that channel, and deletes the messages every two hours. And that was, that's also a really good example of a power of a good platform, doing good things is that it allows people to solve problems for themselves. Because there's a lot of cases where, you know, a lot of people have a lot of feature requests. And this isn't to say that they're like trivial feature requests. There's some things that people want—
PF No, no, at this scale, a million people want a million things. Absolutely.
MB And some of those things would be like profoundly valuable to individual people based on their use case. But you know, as a product company, you can't build everything for everyone. And in a lot of cases, if you try, you'll completely ruin the product, right? So you have to be like really careful in like curating your project, your feature set and to create a comprehensive product, one that that is like comprehensible.
PF How do you? Right? Because now you've got a million feature requests, okay. And there's only a certain number of people on the other side. Talk a little bit about that decision making process, because I'm sure everyone listening has had a million feature ideas and, you know, emailed them and wondered, like, why didn't that get into the products?
MB Yeah, I think there's two ends of the spectrum. There is the one that's more sort of top down driven or strategic driven from the company that says these are our major initiatives, we're trying to accomplish as the company, and we try to align initiatives. But you know behind that, and we try to line up features underneath that to try to accomplish those goals. And then there's the other end of the spectrum, which sometimes people call paper cuts, or these features that are like in high demand for users that aren't necessarily tied to like our strategic initiatives that we balance working on both those things. And we know they're really important. We know that, you know, customers and users using, you know, Slack and being happy with it is like really important to their day to day and then being productive. And so in that you're just, you know, we're prioritizing. So we do things internally. Like, you know, we use JIRA to track issues coming in and backlogs and these requests, and we tie them back to Zendesk tickets, we also use Zendesk, they're sort of numbers that we try to quantify some of the demand for some of these features, at least that come in from support channels. And so we have that, we have, there are other mechanisms where if you have like a an account, executive or person that's like that you work with that helps funnel these requests in, we have channels to be able to submit these requests and organize them and at least get the PMs that manage those parts of the product aware of that, that challenge, not just the feature request, but what the, you know, the underlying sort of friction or problem or thing you're trying to accomplish is because that's really usually the more important thing to understand.
PF Help me understand what a product is at Slack, right? Because like, you know, I download the desktop app, and I log in and it goes, and then I'm off to the races. And so that's the product, and then there's all the sort of things going on in the backend and enterprise relationships and so on. Like, what a product owner be in charge of the—or like, what how granular does it get? How do you break this thing down into pieces that people can actually manage?
MB It's broken down into a fairly granular level. And we it is, it's interesting, because it is one product, ultimately, that brings it all together, there are a few add ons that you could you could purchase, there's some enterprise features, there are levels of our product, but ultimately, it's one cohesive product. And so that's where like alignment of these initiatives are so important. And so there are teams that are focused solely on messaging and the messaging experience and like the composer experience, that's all they focus on all day long, is composition and making that better, and fighting off the tendency to say, do we add one more button? What will that you know, what will that provide? How much, you know, we always assume that's like, if we could just remove clicks, that's better. Actually, it's worse. If you have every option available to you at all times, it's just absolute decision fatigue. Like, it's all these things that aren't important. And it actually is better. Like if there's a catalog of how I use certain features in the product, where I know that I, you know, you have these these paths that you go down, it's like I go down here, I turned right into turn left, and there it is. And it's there when I need to if it's not on my face the whole time. And so there there are teams that are like hyper focused on certain aspects of the product, of one, trying to improve them, and to not ruining them. Because I think, you know, when you're successful a successful product, you're more likely to ruin it than you are to make it better a lot of cases.
BP Yeah, that that actually gets us to one of the articles we're discussing. And I think we can put this in the context of slack or other things, which is preventing scope creep. So like, I love what you're just saying, you know, each sort of piece of the overall, you know, Slack experience has a team and they're not only thinking about relentlessly, sort of about how to improve it, but also how to defend it, you know, internally and externally, somebody might have a feature idea that comes in from a tangent, but you know, is going to interfere with, yeah, sort of like what they see is the essential experience and maybe try to boil it down actually make it more confusing. Mike, like, when you think about scope creep and managing that, is there a difference between doing it when you were at the office, and you were rubbing shoulders with people and you were having meetings in lunch versus now everybody working remotely, kind of in isolation, and often yeah, like maybe if they're doing smaller projects, doing that in a sort of largely remote and asynchronous way.
MB I think some of the things that are different are just exaggerations of what already existed. And I think that when it comes to things like scope creep or misunderstandings of what you were trying to accomplish in the first place, which I think happens more times than not, there's like breakages, or inefficiencies and communication and alignment. I think it really comes down to that and having and where and it really depends on how teams are operating. Are you operating as a single unit with shared goals and shared vision and working toward the same thing, and we have that same level of understanding or when you're in the like agency mode, you're in more of a like a provider, customer kind of relationship where things are sort of contractual, there are hard costs. But even in that case, I think a lot of times it comes down to misunderstanding of what our hard constraints really are. And I really love the way you know, Berné Brown puts it when she says clarity is kindness. I think when it comes to scope and schedule and project and software, that that's kind of key. And that we need to make it really clear, when we say we want to add some new feature, let's say to some project that has some schedules working on already the response that should be we could do that. This is what it could take. But that will mean that there's got to be something that gives, right so, and whether that's the triangle of, you know, scope, timelines or people working on it, there's a negotiation that needs to happen there. And I think the more that we can drive to the clarity and work in the bounds of reality, the better. And I think that the way we've been working now, where if you were used to having all those conversations in person, and there being like, no friction and being able to resolve that moving to this, this space where everybody's not in the same room, and there's just more friction to be able to ask for clarification, to overhear a conversation. And I think if you work in that way, is probably a much harder transition for you.
RD Yeah. And I think one of the other things that makes this scope creep hard for a lot of people is that working remotely, you no longer have the hard separation between home and office, right? It's so easy for office to kind of bleed in. So you no longer have such a fixed amount of resources, people's time. You know, you add this feature on from the paper cuts. And people are like, oh, sure, I'll work a little bit after dinner. I'll add that in.
BP Yeah, I was just alerted by The Telegraph this morning, that there's a microgeneration born between 1980 and 1985. We're known as geriatric millennials. I think we're the one, I just miss the office so much, man, I can't adapt. I'm old and creaky even though I'm not quite 40. And I do think that when I talk to people who are younger than me, like this shift to remote life has been a breeze for them. Like, I started out in an office without Slack and chat being the sort of, you know, the given and they didn't. And so like for them, it's just not as much of an adjustment at all. Like, I actually used to get freaked out in the newsroom, when I would realize that nobody had spoken to each other for hours, like we were all just sitting at our desks, and we might as well not have been there. But I guess one other thing, thinking about this, before we get to the end is, you know, like we were just talking through sort of like, yeah, how do you manage these things? And Mike, I like what you're saying, which is that it's not so much about sort of, like the physical or technical logistics is the security. It's more about, you know, your expectations and your alignment, you know, your ability to understand where there might be friction, or how you can sort of get on the same page with people. Just before we go, can you pine for us a little bit about how that might relate to being your own operations department? We actually had some interesting developments. This week, we had Netlify on the show. And they talked about, you know, creating this sort of really useful build and deploy preview, that can be shared across all departments. So one of the sort of things that used to get in the way was like, oh, I want to see what the web page looks like and get my feedback from the marketing team. But I don't actually have a GitHub account, or I'm not, you know, actually that used to using one.
RD Yeah, yeah, I think we've had some some blog posts, we had a great one from Charity Majors at Honeycomb, about, you know, making the feedback loop in in CI/CD smaller, and making the devs into the operation permanent, kind of makes that loop into a dot. It's sort of an interesting, like, getting rid of the middleman, you're writing run books for how to make, you know, take care of your, your cattle and or pets in production. And like, you know, somebody's got to use the runbook, somebody's got to test it. If the person writing it is the one testing it, there's no friction there.
MB Yeah, I think you're I think you bring a really good point that the tighter you can make the feedback loop or like the distance from the possible pain, the better. Because once you are in a position where if I make a change, and I push it, and I don't test it, I don't review it, I expect someone else is going to do that. And it lands and I like I take down our whole service and the company loses a bunch of money or, or whatever. Like the closer you are to that action to that response, the more careful you're going to be. As well as if you have the sense of responsibility. And let's say you're the one that's getting constantly woken up in the middle of the night, it's not only your responsibility to support that it was your fault in the beginning. And it's also your responsibility to fix it. And so our mindset as engineers should be how do we fix this? Like, how do we build more protections in place? How do we how do we ensure that people, you know, make good decisions? Because it's not just like, do better? It's like, how do we protect ourselves against ourselves, which is where you know, things like percentage based rollouts, or feature flagging, or automation, I think when we think about like, you're being your own ops, for me, it's really about what are all the things I can set and forget? Like, it's not any good for me to automate stuff that I have to keep an eye on all the time and be be worried if it's gonna work. If I can literally, you know, merge a PR and I know it's going to go through some cycle on some pipeline and get deployed and show up and I don't have to worry about, I know if something went wrong, it's going to automatically roll back. That is incredibly empowering and a huge time saver to be able to automate. And if I know that if something goes wrong, I'm going to be notified right away and that's where I think like you know, we use Slack a lot in Slack. We have channels for everything. These notifications come with the channels where you have like notifications set up to be alerted right away. You get a DM when like your PR broke, the build didn't break up. summers yet didn't make all the way out. And I think those two things are really important. It's like both automation and having the teams that are responsible for building the products responsible for running the products. And that usually leads to better outcomes.
PF Related to tha, you've got 10s of 1000s of engineers listening to you right now, you're running a large product org, you're you're at the forefront of this product, you're putting all the pieces together, the design, the engineering, it's all coming together into a more and more cohesive whole. You're looking a little bit in the future. What do the engineers in your world, in the world more broadly, what do you wish they would go learn? What do you wish that they knew? so that they could work more effectively in the the brave new world we're building?
MB Yeah, I think so many times, as engineers, we tend to work in these boxes. And some of them we think, are imposed upon us. And a lot of them we create ourselves. And this is either, I'm a front end engineer, I'm a react developer, I'm a back end engineer, I'm a DevOps engineer, I can't do that. And I think that at the end of the day, it's bits, and it's hardware, and it's, you know, electrons over wires. And what I wish people would do would be more willing to step into these areas of discomfort, and learn even just from an empathy perspective, because you don't have to know how to do it, you just have to know how to wield it. And I think Amazon and AWS is really great at allowing you to wield really powerful technology, if you learn how the abstraction works without needing to know how all the details work. And so I wish people would have this comes into play too. And we think about, you know, technology choices and product choices and things. We think that we're stuck in these boxes. What is it turns out, we have a lot more options.
PF Alright, so broaden your awareness and knowledge without being parochial about specific technology choices. Remember that the computer is a computer, not like a box of JavaScript.
MB And don't identify yourself as some technology. I am a GO developer, I am—you've been in this industry a long time, that changes and your identity will change.
PF And I'm where you are man. I'm like, yeah, but it's just a lot of light switches turning on real fast. I hear you. But I gotta make the box blink, you know, so let's, let's focus on that part. I think that's really tricky, right? Because the product focus translating all the way down to getting something done. There's like five cultures in between, not just like five, five hierarchical levels of an organization, but actual whole cultures of getting work done. And so like that translation is hard. But yeah, no, I mean, I think people should, product sensitivity is a great goal for engineers moving forward.
MB You know, as we move forward out of this, this pandemic, which by the way, is an odd thing to say, it's like part of our vernacular, do you ever think three years ago be like, by the way, how's your pandemic? It's like, anyway, as we move forward, at this time, I think, you know, there's a lot of speculation about like, everything's gonna change everything, you know, we're gonna go about or we're gonna go back to the way it was. And there's a lot of opinions. And I think that I think we know, I feel pretty confident that things are going to change, they're not going to go back to the way they were, they're also not going to stay the way they are. Now from our perspective, from Slack's perspective, we've done a lot of research, we have a group called a future forum that's done industry collaboration with a lot of sort of deep research over the last year, about why we the way we think things are going to move forward. And we're very much focused now not on is it in person is remote, but that things should be digital first. And so I think as you think about how you move forward with how you work with your teams, and whether or not you're in the office or not in the office, I think thinking about things from a digital first perspective, is a really good way to frame how you move forward and how you think you're going to operate as you know, in the years to come.
[music]
BP I'm going to read us out a lifeboat batch winner. That was somebody who found a question on Stack Overflow with a score of negative three or less, gave an answer and got it up to a score of 20 or more. So awarded two hours ago to averroes, "Check if integer == null"
PF That's a classic.
BP We'll let you know. There's a way to check.
PF That's a classic. Oh, my goodness, null.
BP It'll be in the show notes. Alright, so now we're all gonna say who we are and where we can be found on the internet. If we want to be found. I'm Ben Popper, Director of Content here at Stack Overflow. You can always find me on Twitter @BenPopper. And you can always email us podcast@stackoverflow.com.
MB And I'm Mike Brevoort. I can be found on Twitter or GitHub and many places just as @MBrevoort. That's one E, two Os. And I am the Platform Architect at Slack.
RD I'm Ryan Donovan, you can find me at the Stack Overflow blog or Twitter which I don't really use. I don't know my own handle there. [Paul laughs]
BP Great, we'll just I'll just put that in the show notes. So people want to go to a Twitter account that is rarely active. Go check it out.
PF Yeah. My name is Paul Ford. I'm a friend of StackOverflow, good friend, I think. And you should check out our company Postlight, Postlight.com where we are hiring a product managers, designers, engineers to do all kinds of very interesting work across a whole lot of industries. So I would love to hear from you.
BP Terrific. Paul, at this point, you're the show's best friend. I mean, let's be honest.
PF I should be, I mean, you know, I'm here, I show up every time.
BP I don't know if it's live yet, but you can go check out Postlight's company page on Stack Overflow. We helped them set that up. It's got details about the company and positions you can apply for.
PF It's all worth it now. Yeah. Oh, my God. Yeah, no, we are we are just seeing that growth.
BP Yeah. And if you want to put Slack and Stack together, you can head on over to StackOverflow.blog/teams, you can sign up to use Teams for free. That's our knowledge management tool. And it's got a great integration with Slack. People just ask a question in there, pops it up, populates it into a Stack Overflow for Teams question, you can save that knowledge forever, instead of having to go back and find it somewhere later.
MB I will say that I have been using, I think I've used Stack Overflow about 50 times this week, as I've been working on something. And it's felt like the teammate you could turn to and just ask like, how do I do that again? I think I'm in between like four different languages. And I think like you know, Stack Overflow for Teams is like having that teammate next to you that you could just, they don't want to you know, anybody else do like, I don't want to bother and ask again. I want to do the work. Just ask. Ask and there's so many answers you can find.
PF Alright, alright. We did it. We did it. We solved all the world's technology problems... again!
[outro music]