Ben: Hello everyone, and welcome to PodRocket. Today I'm here with Mike Brevoort, who is the Head of Product Developer Platform Experience at Slack. Did I get that right, Mike? Mike Brevoort: Yeah, close enough. Ben: Close enough, that's all I could ask for. Well, really excited to have you on the show today. I think everyone knows Slack, we use Slack, I feel like everyone does nowadays, maybe there are some people that use other things. But, really excited to kind of learn about what's going on behind the scenes in terms of developer platform, and making Slack a place for developers to build on top of. So, maybe you could start by giving us a quick background of, what does your team do at Slack, and everything from there. Mike Brevoort: Yeah, thanks, and thanks for having me. Yes, I joined Slack about three and a half years ago through acquisition, so they acquired a company I created called Missions, which was a mission-based workflow system. We had built on top of Slack, we actually built on Slack. First we built the bot hosting platform, and then we pivoted that to this workflow system that was for not developers, but for people, like really anybody building lightweight workflows on top of Slack. So joined Slack through acquisition, then went on to build Workflow Builder, which is the lightweight workflow capability inside of Slack. And has sort of gone through different roles, as like engineering, or managing engineering teams in Slack. Mike Brevoort: I took a detour into an IC role for about a year and a half as a platform architect, to help sort of envision sort of the next wave of platform at Slack, and now I have shifted into a product role. But the platform, when we say platform in Slack we mean the API platform the developers can build on top of to connect with our customers. And the majority of development that happens on top of Slack is by our customers, but we have a pretty rich ecosystem of partner, like third party developers that go on Slack as well. Ben: Got it. What I'd be curious to start with is understanding the kind of full landscape of ways that a developer can build on Slack. I've done like a little bit myself in various times, in terms of using web hooks to send messages into Slack, building some really simple Slack interfaces that let someone do a slash command, and then interact with buttons, and some of those type of things. But I feel like I don't really have a sense for the full gambit of what are all the ways that one could build on top of Slack, so maybe you could take us through some of those, we could talk about some use cases, so kind of give folks a better idea of what can they build using Slack as the interface layer? Mike Brevoort: Yeah, we've added a lot of things over the years, in addition to just being able to send messages as a bot in Slack. So you can define custom interfaces that you can raise a modal, like a custom modal interface that can be interactive, there's like an app home-type interface with your app that you can go to and have like a customer interface. It uses this toolkit called Block Kit, which is like a JSON language for describing device-agnostic UI. So like our mobile applications, render that in a native mobile way versus our web app. But, you don't have to deal with that. But, a lot of the use cases are still around data that comes into Slack. So you have channels that you set up, and there are four purposes. So they're like a team, or for alerts, or for projects, or whatever. Mike Brevoort: And the magic of Slack usually comes together when you bring together certain people for a certain purpose in the channel together with the tools and information they use. And so if you have a team that's working on a particular account, that they're working on a sale or renewal, and you could get that group of people and that focused area updated when certain key things change, then pushing that information into Slack, into that specific channel, is a really valuable use case. Being able to act on that is also valuable. So, if you could take action on something in Slack as that occurs, that either gets pushed back into like that system that generated it. And so, or, there's a lot of use cases around information coming into Slack, being able to act on it, as well as enriching the information that people share when they're using Slack. Mike Brevoort: So if I send you a link to a document, we unfurl that document. And as a developer, you can provide a custom unfurral that gives you a preview of what's inside the document, and with actions too so there are buttons and information that you could take to act on that information. Ben: And I guess looking to the future, what are some... To the extent you can share, what are some other ways that Slack envisions letting developers build interfaces on the platform? Mike Brevoort: Yeah, I think to date we've just continued to add more and more features to the platform, to allow you to do more, to build more robust apps on Slack. And I think the challenge has been that those apps have been largely self-contained, so if you build an app, let's say for PodRocket for Slack, and you would install that into Slack, that app can do a bunch of different things. It has this app home, it has a way to send messages. What we haven't done really well to date is add this structure and repeatability around how a user configures that app to do the things you want it to do. And that's been left up to developers today, so you install the PodRocket app, and the best thing you could do today is like send the user a message that installed it, in a DM that's like, "Hey Kate, thanks for installing this app. Mike Brevoort: "This is what you need to do next, you could run a slash command, and you could go to a channel and set it up this way." And it's really up to the developer to be able to coach a user into how to set their app up in any of these contexts, and we haven't established sort of well-worn patterns or conventions for developers to build to where users really understand, what is an app in Slack, how do I use it, how do I set it up? And if I use one, so I find one, and I find it useful, and I'm successful with it, I should then know like, "Oh, I know how this works now," and I could set these others up. So, that's one thing that we're really working on, is one, making it more conventional for users to be able to work with these integrations that people create. Mike Brevoort: So, more discoverability in the product, more ways for you to interact with them, in more meaningful ways. The second is that every one of those apps that people would build, even the really robust ones, they're really islands. They operate independently, they don't really work with each other, and they tend to work in a single way. So it's however you as a developer created them to work, is how they work. And there are a lot of products out there that are very complicated in terms of the ways you can configure them, like Jira is a really good example. You can in Jira create different issue types, those issue types can have different fields. And, you could really customize Jira so your Jira instance is much different than mine. Mike Brevoort: And so if you build a developer experience for that, you either have to account for all those differences for how someone could set your product up, or what we like to do now moving forward is make it so that instead of you having to build the end-to-end experience for how people experience your product inside of Slack, then you can build more modular components that can be remixed with components that come from other apps inside of Slack. Like for example, inside of our Workflow Builder product that you could start combining capabilities from apps, and set apps up to work the way you want them, in the combination of the way like data flows between tools and you use them. Ben: Got it, yeah. No, super interesting. And so, I'm curious to look a bit more kind of at your role with Slack. I'm curious like, what does your day-to-day look like, how do you kind of figure out your priorities? Mike Brevoort: Yeah. I think the biggest thing for me has been that, or the biggest challenge has just been to economize my attention. And so regardless of the role I've been in, I think that's always been just a challenge, is so many things demanding your time and attention. There's people putting stuff on your Calendars, there's back messages, there's emails from outside, there's just... There's so much, and I think that the hardest thing is just to decide like, "What's the most important thing I could do today? What would be the best investment of my time?" And so, my days aren't really prescriptive as much as they are planned around that. Like, if there's one thing I could do, or two things I could do today, what do I focus on? And all the other things, for better or for worse, tend to kind of fall by the wayside, and they may be a priority tomorrow. Mike Brevoort: And so, that's anything from... Especially in a role, in a product role now is, does a team, does my team, and my engineering teams know what they're building and why, is it moving? Are people continuing to move? And if not, that's like a really big priority. Is it looking further ahead? There's obviously tons of meetings, lots of one-on-ones connecting with people, there's strategy long-term meetings, there's customer meetings, there's partner meetings. But day-to-day, it really is just looking at, what is the highest impact thing I could do today, and really trying to focus on that, and realize I just can't do everything. Ben: And what is your overall philosophy on what a developer platform experience team should do? I'm curious specifically at Slack, and then for other companies thinking about how to maybe start off such a team. Like, what should the kind of, the mission of that team be at the organization, what other price the organization should interact with, how should it report in the organization? I'm curious on all of those things. Mike Brevoort: Yeah, I think it really depends on what you're trying to accomplish by providing this developer platform, so instead of APIs for someone to integrate with your product. In some cases, those APIs are just to automate the product. So, you need a product, and people need to use it and get value out of it, and then you create APIs so that they can automate what you do on that product. There are other platforms that allow you to create experiences inside of your product, so that your product is a shell or a canvas for the things that they can create, or they can customize on top of it, and I think that's very different. And so it depends on what you're trying to accomplish, like at Slack we're somewhere in the middle of that. Mike Brevoort: Where you can automate the aspects of Slack, there's APIs to call to be able to send messages, create channels, invite people to those channels, and terraform Slack, like automate it as well as send messages from outside. But there's also opportunities to create experiences inside of Slack, and that way the platform is really part of the product. It's both the way to use the platform as an extension of the product through APIs, but it also allows you to create experiences on top of Slack. And so, we're part of the product engineering organization. But, I think it really depends on what you're trying to accomplish as part of the platform in terms of where you put platform in an organization. Ben: Got it. How do you think about team-building, in terms of the type of folks to add to the team, and specifically for engineers, are you looking for kind of the same prototype, or archetype, prototype of what a typical Slack engineer would be, or do you look for a different skillset when you're adding engineers to the team? Mike Brevoort: Yeah, we value diversity immensely at Slack. Which is not just diversity of like background, or gender, or what you'd come to think of, but just diversity of thought and experience as well. We find that the most diverse teams are the most resilient and successful teams, typically. So, we have a career ladder with levels, and in our highest levels we have a breakdown of archetypes for how we describe what type of engineer, what type of contributor are you, because we know that they're different. There are people that for example are really good starters, they're just really good people to just initiate new things happening, new ideas, and driving, and getting those things going. There are other people that are just really good generalists, people that, if you add them to a project it's going to just make the whole thing, I don't know. Mike Brevoort: There are other people that are really, really good, like expert, industry-leading level at their craft at a very specific thing, and that's all they want to do. And so I think, one, we look at, we're trying to fill a role on a team. And so, I think we need to consider what that team needs. A team is a group of humans that work together, that should be focused on a common goal. And I think that the most important thing is that you have this group of people assembled to be able to accomplish that goal, and so any time you're looking to fill a role on a team it's a new opportunity to be able to add to the abilities of that team. And I think that sometimes you get teams that are overloaded in one way or the other, where you have a whole bunch of experts, people that are good, or tend to do certain things well. And I think that looking at... As an opportunity to balance that and offset that, is at least in my mind opportunistically the best way to approach it. Ben: And looking at teams, and kind of teams, and process, and collaboration, obviously Slack is one of the core tools used in the modern distributed team. Obviously there are competitors as well, but Slack is certainly one of the thought leaders. So I'm curious, I'm going to go out on a limb here and guess that you use Slack as Slack. But, but curious what other tools you use in terms of collaboration and workflow on the team, and maybe how those play nicely with Slack as well. Mike Brevoort: Yeah. I think we know Slack isn't the end all, and if we tried to make it the end all we would ruin the product. We just need Slack to be really good at what it's good at, and we need... And part of the value of the platform is to pull together the other tools that you use. So, we use a variety of documents for that, or some things that are in Google Docs, and Dropbox Paper, and now Quip and some other things. We obviously use all the common development tools. We use Zoom obviously, we use... We have some newer features of Slack that have been profoundly impactful, at least to me individually, which is this... I tend to record and share a lot of videos, especially working remotely. Some people use Loom a lot for that, or other products. Mike Brevoort: I've been playing with Dropbox Capture, which is in beta now, and some others. Or just for recording videos on your own, and sharing them. Slack has a built-in way now to make it easier to record those videos and share them as clips, but you can also record them and just share them, it doesn't really matter. And so, in a lot of ways it's replaced... We've replaced a lot of meetings through these async clips instead, like status-type meetings that are higher fidelity of explanation, versus just text. We also have a feature called Huddles, which is like, you could jump into an audio channel for any channel, which has been a great way of Teams. But outside of that, we use all the other common tools that people use, especially from a development perspective. Mike Brevoort: I've been using GitHub, and others. But, it's harder at a larger organization because to be really effective a lot of times you need people using the same tools. And so, it's a bit harder sometimes to experiment with new tools that aren't just like... There's some tools that help you individually be more productive, that you don't require other people to use, and there are certainly other tools that you require everybody to be able to use and be effective. Ben: Yeah, before you joined Slack, and you mentioned you founded a startup, which I'm curious to learn more about in a few minutes. But, what I'm interested in is, going from the small startup environment into a large organization like Slack, can you talk about the different classes of problems that engineers have to solve in each, and what... Maybe anything specific to Slack as well in terms of problems you've faced there that other companies don't have to deal with based on scale, or there's the products base. Mike Brevoort: Yeah, I think it's a good question. It's different, it's definitely different coming from a small team and joining a really large team in a number of ways. One, there are these pre-determined roles in terms of what you expect an engineer to do, or what you expect a product manager to do, what you expect a designer to do, or whatever parts of the organization, like product marketing manager. Those are well-established in a large company, whereas in a startup they're established, but people tend to wear a lot of hats and contribute across lines. And I think that's one thing. When it comes to being an engineer inside of a large tech company, I think there are a lot of differences too. One, these types of companies, like Slack, like Facebook, like Netflix and others, tend to build a lot of tools. Mike Brevoort: And those tools solve a lot of complicated problems around automation, and deployment, and scalability, in that... And those tools are amazing, because it allows any engineer to come in and build for that scale. However, once those problems are solved by those tools, they're solved. And I found a lot of time when talking to people they were like, "Oh, you work at Slack, you must deal with really hairy, big scalability problems." Or, "You've worked at Google, certainly you must be like the most amazing engineer because you built for scale." And the reality is, it's true in the extreme case. I mean, it's true, you have to understand certain attributes of being able to operate for scale around how data's organized, or certain aspects depending on... Mike Brevoort: Really depending on the tooling that's created, or the frameworks on top of that. But most of those engineers don't have to solve those problems, because it's already solved. A lot of it is like, sort of color by numbers in a lot of these cases. And sometimes it becomes really detrimental, because you tend to look at the ways you would solve certain problems because it's a lot easier to build on top of existing tooling and frameworks and infrastructure that you have at your disposal that have already solved those complex problems, versus going off and doing it differently. Because going off and doing it differently means that you have to bear all that yourself. Like for example, when we joined Slack we had to make the decision of whether or not to... Mike Brevoort: Do we continue our current code path for the Missions product, or do we rebuild inside of Slack? And so, we kind of went both ways, we rebuilt the front end, and we took some of the back end, and we decided to continue it forward. And so, we deployed our Missions service, our back end, which was a go service, to Slack, and it was on top of Kubernetes, and Slack was just starting to sort of operationalize Kubernetes at scale. But, there was all this crazy network infrastructure that happens, and there's a project called Nebula, which is like... I don't get it, it's all these networking layers. And, our team had to bear all this complexity of working with teams at Slack, but trying to make that work with all the existing tooling, to be able to operationalize it and run it. Mike Brevoort: And the part of being able to continue to program and go was like a small part of that, and the part that really was difficult for us is just all the time of making that work into the Slack infrastructure, versus if we were to say, we were going to build it in Hack, which is what Slack is, and Hack is like an evolution of PHP that came out of Facebook. Slack happened to be built on top of PHP, and is now Hack, which is a tight version of that. But there's like, an immense amount of tooling at Slack to support development on top of Hack. And all these problems were already solved around just, how you share out and manage data, how you sort of tap into the real-time nature of Slack. And so, no, I think it's very different when you join a large organization. Mike Brevoort: Because it's a lot harder to do things new and novel without significant investment, because those things don't necessarily work with the tooling infrastructure that exists. Ben: Curious to learn a bit more about Mission, that was your startup that was acquired by Slack. A bit more specifically, what was your goal there, what was your mission there, so to speak? I couldn't help myself. And what was the product, and ultimately why did it make sense to join Slack? Mike Brevoort: Yeah, so we had... Before that, we started building this product called Beep Boop, which was a bot hosting platform. And when we decided to build that, I'd come from a few other projects, people I was working on, and we did integration into messaging platforms as part of these projects, not like as a primary thing. So, we were building this big ed tech product, this one-to-one delivery program with a partnership with the University of Texas. And when we built up all the infrastructure for that, and it continues deployment infrastructure, we did a really heavy integration with Slack. Slack was the way we deployed software, it was the way we got updated, it was actually the way that we notified our customer we were working with when we did deploys. Mike Brevoort: And there was a lot of visibility and operationalization on top of... On Slack. Previously it did that at... On top of [inaudible 00:22:08] chat before, and just saw how tying these tools and processes into a messaging platform as a really lightweight interface was this sort of magic thing that was hard to replicate if you tried to build from scratch. Like, when you build on a messy platform, you already have authentication, authorization, you already have basically like a little bit of a UI framework, you have the contextualization of channels. We have a lot of building blocks that you could tie into. And so, we were looking at opportunities to integrate into the messaging platforms, and we thought it was really interesting to build tools on top of messaging platforms. Mike Brevoort: And so, we built out this CICD mechanism to take a lot of sort of bot shots on net, as we called it at the time. And then as we got three weeks into that we were like, "Hmm, you know, everybody's going to have to do this." And at that time, building bots involved connecting the web sockets, and scaling high density of web sockets if you wanted to do that, and it was actually kind of difficult from an infrastructure perspective. And so we were like, "Hey, maybe this is the product, maybe actually a hosting platform [inaudible 00:23:10] bots." And it was right around the time where containers were coming to life, where people were starting to talk a lot about Docker, and containerization. Kubernetes had just been launched, and we had this idea that, well maybe a bot's like a container, maybe it's an agent. Mike Brevoort: Maybe it's like this autonomous thing, and there's like an interesting sort of parallel there. And so we set off, and we started creating a bot hosting platform. It was like, pre... It was right along, we kind of rode the hype cycle, it was before Slack launched a platform, it was before Facebook launched a platform, and Telegram. So once those platforms launched, we supported them. But, we were like, we had huge adoption, but something was just wrong. We were like, "You know, I just still don't see the demand for bots for bots' sake, especially not on the consumer side," and just integrating with messaging in that way. But we saw this interesting thing people were trying to do on the for work side of it, where they were trying to build these tools that helped their teams work together. Mike Brevoort: And so, we decided to kind of pull back, we pivoted the focus more on the for-work use cases, trying to understand that more. And there were a lot of people coming to use that developer platform that weren't developers, so they were product managers, they were designers, they were really anybody that was like, "Oh, if I could just make this work with Slack, if I could just get this to happen, that would be amazing." And they all came, and we did... I was really proud of our onboard, the guy who onboarded, as long as you sign into Git, did the full setup, like we had a Git repo, it automatically deployed on chains and all that stuff, and we had this whole conversational walkthrough. So everybody got through the onboarding, almost. Mike Brevoort: But then it was kind of like, when you ran out into the... It's like, you know the scene in the movies where you're on Mars, and people run out into the atmosphere, and they're running, and some people fall down and collapse and die at like 15 feet, and somebody else perseveres on. But ultimately they die, like they get far and they all... And Survey died, and so they weren't very happy with all these people dying using our product. And so we decided like, "Wait a minute, there's this huge need that's unmet there, and people want to be able to build on top of Slack. They don't want to build apps, but they want to just build these lightweight tools." And that started to feel a lot like workflow, and we were looking at what people were trying to do. Mike Brevoort: And it felt like... And we thought about workflow, we thought that it seems almost like a good story. It's like things that have a good beginning, a middle and an end. And so, people were trying to accomplish these tasks, which led to the name Missions. We were like, we're trying to sort of give people these abilities they didn't have to be able to accomplish these missions, and to set off and make them successful. And we wanted them to feel like they accomplished something when they were successful. So, we pivoted that, and we looked at the sort of workflow space, and we were like, "Wow, enterprise workflow sure are complicated, certainly they don't need to be. What if we gave everybody these simple, lightweight tools to be able to automate the simple things?" Mike Brevoort: Like, not go crazy, but be able to do that on top of a Mission platform like Slack. And so we started with Slack, we had a deep partnership with them already in how we built on top of our platform, we had the bot hosting platform. And we had very [inaudible 00:26:13] intended to support other messaging platforms, like Teams, and [inaudible 00:26:18] Strive at the time, and others, maybe even SMS. But we were at this crossroads where we were going to do that, we were going to kind of broaden our total adjustable market. And we had to decide... And I mean, we were kind of headed off, and the part that we weren't as excited about was, the platforms seem really similar but they're actually really different. And we have to basically build the least common denominator workflow product on top of a messaging layer. Mike Brevoort: And we were going really deep in Slack, we had been working with their biz dev team. And they kind of knew that we were going to make this decision, and one thing led to another, and a conversation where we started to casually be like, "I wonder, what would this look like if we broaden into Slack? What would it look like as a part of a product?" And I already talked about the market side that we got about what that could be like, and there were a lot of problems that we had been trying to... Had been difficult to solve on the outside of Slack, that we thought that it's like, "Oh wow, if we built this product inside, if we built it as a part of Slack that any Slack user could use..." We saw the impact that it could have, and so we kind of took the bait and decided to join Slack. Ben: And are you happy with the decision? Mike Brevoort: Yeah, yeah, I think so. I think it's easy to speculate, to be like, "What would have happened if we would have stayed independent?" I mean, there have been a lot of workflow kind of companies that have launched, or been really successful since then. And so I look back and I'm like, "Wow, we could have done some amazing things." But, I also look at what we did within Slack, and I'm pretty proud of the Workflow Builder that we created, the usage that's gotten, and the impact that it's had. And now, the influence that that journey has had on the sort of future vision of platforms at Slacks, it's been an amazing place to be. I mean, Slack is just a tremendous organization, like really deep values and culture, and just, I've gotten the opportunity to work with just some incredible people. Ben: So anyway, I asked earlier a bit about the future of the ability to build interfaces, and develop a platform on Slack. I'm curious more broadly, what are you most excited about over the next few years to the extent you can share that's coming out from Slack on the road map? Mike Brevoort: You know, we just... We want users and people that use Slack to be more productive, and to enjoy how they work, and we want developers to be able to assist them in accomplishing that. And so, I think giving developers more tools where they get more... That they could just get a higher sort of ROI based on what they create, and that's a level of effort, it doesn't have to be so big. So, they could create little things that people could use in really meaningful ways, that they don't have to think of all the possibilities that could be remixed, and we just make that just easier for people to just build things in Slack that users can use that make a lot of sense, and that people get value out of. I think from a Slack perspective, we could add a lot more features to the platform, and I think that that won't really make the difference. Mike Brevoort: It's really just about, how do we make it easier to build, how do we make it easier for users to use these things in really meaningful ways? Like, meaningful that feel like they belong in Slack, they feel a part of Slack, and it's not unnatural that we're trying to build these experiences inside of Slack, and keep you inside of Slack, instead of keeping you from going to some other product. Whereas I think, sometimes the best thing we could do is make it easier for you to get into the other product, like you share a link to something and there's... Early on Slack, it was like trying to... You shouldn't have to context switch, and we should keep you in Slack, and you should be able to complete what you're doing without having to switch to this other product. Mike Brevoort: And I think that a lot of ways I've looked at it is like, if we'd just made it easier for you to get into that other product, like there's some features we're working on to allow you to have implicit, single sign-on links for example. Like, how do we just make you get past sign-in, or be able to provision accounts on the fly in that other system? And so that's some things on the Slack side. I think outside of Slack, I think just web dev in general is super exciting, with everything that's happening between all the frameworks and platforms that are starting to... I'm really excited about tools that abstract away the computer. I think that we've done that on the server side, run time side, but still, your development experience is still like a bunch of files on a system. Mike Brevoort: Even when you're importing files, you're referencing them, and you're culling them, and you have to have all these tools set up locally. And I think that VS code spaces, and a lot of the moves to these more turnkey package development systems that aren't tied to my local computer are really interesting, as well as... I think the stuff that Dino is doing, and Ryan Dahl, with trying to implement web APIs on the server, and trying to make code more portable in that way, and treating the browser as a container the same way you would the server, so it doesn't matter where things run is really interesting. Because we're still sort of programming in this Linux sort of model, of Imposix, of files and file system and network access. Mike Brevoort: And so, if you could abstract that away, even for the code that runs in the cloud, or the server, or wherever it runs, or actually run that in the browser, like on-client, I think that stuff is really interesting to me. Ben: Awesome. Well Mike, thanks so much for joining us today, it's been great to learn about you, your background, Slack, so really appreciate it. Mike Brevoort: Sure, yeah, thanks for having me man, it was interesting. Speaker 3: Thanks for listening to PodRocket. You can find us @podrocketpod on Twitter, and don't forget to subscribe, rate and review on Apple Podcast. Thanks.