• Slack’s new API
• stevesgill on Twitter

Allen: Welcome to It Shipped That Way where we talked to product leaders about the lessons they’ve learned, helping build great products and teams. I’m Allen Pike. Today’s interview is with Steve Gill. Steve is currently director of DevRel Engineering at Slack, previously was senior computer scientist at Adobe, and did developer relations for the Apache Cordova project. Welcome, Steve.

Steve: Hey, Allen. Thanks for having me.

Allen: I’m glad to have you on. I’m slowly collecting all of the brilliant people that I went to university with, that have gone on to do fun, exciting things. I’m glad to add you to the list.

Steve: It’s always nice to catch up. It’s been quite a while since the university days and nice to see you and others that we went to school with all excelling in this field now.

Allen: Yeah, we went to school at an interesting time where it was like, I think maybe you’re a couple years younger than me, but a lot of us applied to university just during the heyday of the dotcom bubble when it was like, “The internet is changing everything.” And so it was I guess more competitive than it had been in previous years. I didn’t actually get accepted initially even I had to transfer in after my second year because so many people were like, “The internet is the thing. We should learn computing science.” And so I think it created a bit of both an excitement as well as a surge of smart people going into that program. People smarter than me clearly, because I didn’t get in initially.

Steve: I mean I always remember you as being one of the smartest guys in the room, so I think that says a lot. I joined a few years after you, like you said. And for me it like the bust had happened a little bit and people… I remember a feeling of taking this degree and people saying, “Will there be jobs?” “I don’t know.” So there was definitely a bit of gloom there. I likely did get in right away. I don’t know how that happened, but it did. I just have a lot of fond memories from those years, like joining the Computer Science Society, making some friends that have lasted through my professional career now as well. I remember you in the room, you were the only guy using a MacBook at the time, and everyone was just like…

Allen: Yeah, that’s true. And it was a constant, people would make fun of, I’d have this little Mac laptop.

Steve: And look at us now everyone uses a Mac laptop, so you’re a little ahead of the curve for sure. Yeah.

Allen: Yeah. And then we’d have these Unix machines in the lab and I’d be like, “I know this.” I’m sure our audience all tuned in to find out about our university days, but I would also primarily like to dig into a bunch of the stuff that you’ve learned in many years now of building products both at Adobe and Slack for developers, creating platforms developers are excited to build on and also get a chance to learn a little bit about the engineering culture at Slack. Slack obviously is built, I want to keep you all humble, but one of the great products I think of the last 10 years really. Something that came out of nowhere, I think to a lot of us, and now as part of most startups lives and smaller tech companies and even very large number of large tech companies lives is part of the fabric of our experience, a lot of us in technology. So I’m curious to learn about the engineering culture and that you all have there. But first, I’d like to give you a couple minutes to recap us a little bit on the Steve Gill story. We’ve gotten to the university part, I guess. How does you go from university and we’re in the computing science society and wondering whether or not there’s any jobs to being a director at Slack?

Steve: Yeah, it’s quite a story for sure. Well, I guess we can go way back. It all started with my first co-op actually in university, co-op I guess for the Americans internship. And I started at this small consultancy up here in Vancouver, Canada called Nitobi, and we were just a little agency. We had clients, we’d build websites for them, that kind of thing. And some really smart engineers at this company thought of, “Hey, what if we can build mobile apps with web tech, JavaScript, HTML, CSS?

Allen: This was like when the iPhone was just launched, like that year.

Steve: Yeah, the iPhone was just launched. Yeah, it was very early on in that. I remember Android was not far behind either. So they came up with the idea of PhoneGap, which ended up being extremely popular in its heyday. And PhoneGap allowed you to build mobile apps using HTML, CSS, JavaScript. It was open source right from the get go, so we had a lot of people contributing, a lot of companies jumping on board, and it ended up being quite a first project for me to land on. So at that time I was still just getting started. I was doing a lot of DevRel type stuff even back then, so creating videos, creating blog posts, samples, going to meetups and speaking about PhoneGap. And over the years, Adobe approached Nitobi and ended up acquiring Nitobi and PhoneGap along with it. And during that process we wanted to ensure PhoneGap stayed open sourced, so we donated it to the Apache Software Foundation as the Cordova project. And so for many years I continued working on there, doing DevRel-y things, but also transitioning into more serious engineering work, which is something I think a lot of people, who get compsci degrees go with our background, want to feel validated by building those engineering skills. So that was a lot of fun. I got time to build the Cordova CLI and a lot of the accompanying libraries that go along with it. Really got a good handle on Node.js as my primary language and rode that wave for quite a while, just working in open source, working with Google, and Blackberry, and IBM and folks at some other large companies as well, and working collaboratively on this project that was being used by millions of people. I stayed at Adobe for until 2019. So I started in 2009, so about 10 years working on PhoneGap, Cordova. And at Adobe I also kept moving up the ladder, became a senior engineer, started working on open source more broadly at Adobe, created the Open Source office over there and helped Adobe Open Source more of their internal projects, but also make the process of contributing to external open source projects a lot smoother for employees. But in 2019, near the end, it was time for a change and I ended up having my first kid and took the opportunity to apply to Slack. Slack’s a product that I’ve been using for quite a while at this point. It was used at Adobe. We used it even at Adobe when it was just a PhoneGap team. We started just a little subgroup on Slack before it was adopted organizationally. We loved it. I built Slack apps on the side for some workspaces I had with friends. My old ice hockey team was on Slack, so I built a little app to get the scores and post the schedule, that kind of thing. So I already loved the product and when I saw this opportunity to join the developer relations tooling team and work on SDKs and other developer tools, it already fit really well with my experience and what I was passionate about. So it was almost a no-brainer to make the switch when the opportunity came.

Allen: I can see the appeal of that building a developer platform is always a daunting thing, or maybe it wasn’t so daunting when you were doing it. Is it just an interim because you didn’t know how daunting it is. Most developer platforms don’t get any adoption, but when you’re building the developer platform for building on Slack, it’s something that we know just talking… On any team, there’s always someone being like, “Well, maybe we should build a Slack bot for that. So, it’s something that comes with and built in interest, which is cool.

Steve: Yeah. Especially in our field, like you mentioned earlier, so many startups are using it and large tech companies are using it. It just became the hot tool in tech. And obviously Slack is used by a lot of industries outside of tech as well nowadays, but back then it really felt like it was catered and made for us, techies. So yeah, I had already had experience with the platform. I already loved it, saw some areas that we could improve, and this was just a perfect match for me. And then I worked as an engineer mainly on our open source SDKs. We have a line of SDKs called the Bolt SDKs, which we have in JavaScript, Python, and Java, mainly just adding new features as the platform was releasing them, taking feedback from developers back to the platform organization so we can try to add features that they are asking for, because you got to have that give and take with your community, I think. Continued that for quite a while, for about a year and a half or so. And then my manager left and I got offered the management role and I’ve been on that track ever since. Slowly moving my way up, taking on more responsibility, more people, growing the team, and really growing the area of focus for me, not just to developer tools, but now more so developer experience as well.

Allen: I love it. As you know I am all about the experience side of software. So let’s dig into that a little bit now. So we’re a bunch now because that’s a perfect topic for us to talk about is we’re building developer tools. Obviously you have a long history at Slack of building things and you have a long history yourself of building things for developers for now more than a decade. What do you think about when you’re approaching either a whole platform or an individual, an update or a revision or a feature or whatever? What are the principles and approaches that you keep in mind when you’re thinking, okay, we’re going to build something, obviously we want to build something that developers really want and not just a thing that we think is cool, but then no one’s going to care about? How do you approach that category of problems?

Steve: It is not always easy. Right off the bat, I want to say I’ve definitely built things that I thought developers have wanted and maybe they don’t want.

Allen: Yeah, me too.

Steve: So I think that can happen to everybody. But a big part of it is sometimes prototyping and trying and getting feedback and determining, “Is this what developers want?” For me, a lot of it is getting that feedback from developers. So I find by having your libraries be open sourced right away, you already have a direct avenue to talk to developers who are using your tools and building off of them. And that alone will give you a stream of input of what’s working in the platform, what isn’t working in the platform. And therein you could take that feedback to the product managers and higher ups to see if we can get some of that work prioritized or on the roadmap at least. But also, it’s taking a step back for a second. For me, it really comes down to, “Is this platform offering me something? Is it solving a solution to a problem I have at the core?” And if the answer is yes there, then it’s about building everything around solving that problem. So can we expose APIs that developers need to solve that problem? Can we build tooling to interact with those APIs so it’s even easier for developers. Instead of getting super low level, maybe there’s a way that we can help them get to creating value faster. And so that’s obviously the space that I feel like I specialize in or I’ve spent a lot of majority of my career in. And when it comes to building tools, right off the bat, it’s got to be something that is easy to work with. There’s this balance you have to find of being too low level and being almost too… It’s like too in the weeds, too much struggle needed for a dev to get going or to understand to be able to solve their problem. So you don’t want to be too low. That’s what SDKs are trying to solve. You also don’t want to be too high either. You don’t want to be too magical, where devs don’t know what’s happening. So a lot of that comes intuitively from me just being at dev as well and working with other tools and identifying what I like and what I don’t like. That’s one of the principles I take to heart. The other one is I think you really got to meet developers where they are. I mentioned that we had these open source SDKs in three different languages. I really think that Python devs want to have Python libraries to work with, and JavaScript devs want JavaScript and Java, Java and vice versa. So you got to meet where you got to meet them where they are. You got to give them the tools that they want that. And if they’re already familiar with certain stacks, you want to try and fit into those stacks, I think. That’s not always easy.

Allen: Yeah, no, it’s not. How do you think about this trade off? And obviously this impacts smaller teams and startups more severely than Slack because just resource constraints, but every team has a resource constrained. You have a certain amount of resources and you can lobby your manager, your boss’s boss to get more resources. But one of the things I find sometimes and caught up in discussions, and it can cause I won’t say drama, but drama on teams, is figuring out, “Okay, we want to make this SDK really useful for these teams and we want to get adoption, but we have a certain amount of resources. How many SDKs should we build?” Because we can say, “Oh, Python developers would love a Python SDK and JavaScript developers would the love JavaScript’s SDK, but the Ruby developers would like a Ruby SDK, and the .NET developers would like a .NET SDK and the PHP developer’s like… The Clojure developers like a Clojure SDK.” But you have to obviously create some tradeoff and the more different SDKs you have, the more thinly your set of resources is spread. And so you end up with what all the tradeoffs you can think of, but maybe less docs, or less polished, or maybe it’s less idiomatic. Maybe you have one developer trying to maintain JavaScript, Python, and Java. And so the Java one doesn’t feel very Java-y to Java developers, whatever that is. I don’t written Java in 20 years. How do you think about those trade-offs? Is that a thing you think about in any an systematic way or is it just a series of small decisions lead to where you are?

Steve: Yeah, yeah. I mean it’s a problem we’ve had as well for sure. And I do think about it more, I think at a systemic way. Like, we look at the data, we look at what people are trying to build with, we look at our API and if we can get some user agent information, we look at requests from developers in the community. Are they really, really wanting a Ruby one? Ruby’s an interesting one. And so is.NET. Both of those, there actually are Slack SDKs for those, but they weren’t written by us at Slack. So a lot of times you have to depend on enthusiastic folks in your community to also create and maintain. And then from our perspective, all we can really do is support those individuals.

Allen: Do you find yourselves contributing to those words? Like you released a new feature, or they have a feature where it’s like, “We don’t really want people using this. Can we maybe have people use that instead?” Or is it more just like you drop in an email being like, “Hey, can you please add support for this thing?”

Steve: Yeah, I think it’s a little of both probably. Realistically, we try to keep open dialogue with some of our community SDK authors and through that dialogue we try to let them know what’s coming. We also try to find different ways to thank them for their work. Maybe that’s in the past sending socks, something silly like that. But I think devs do want to be recognized. Open source devs do want to be recognized for the work they’re doing. So those are just some of the small things we do. We also try to highlight the SDKs that they’ve written on our documentation site so other developers can more easily find them. With anything open source, there’s no guarantee that those are going to be maintained forever either. So there have been times when we’ve stepped in to help with maintenance, kind of more low level, but it is a resourcing issue, like you said. And we would love to have SDKs to support all the different languages. And I know some companies are doing that automatically as well. They’re using OpenAPI.

Allen: Like Swagger?

Steve: Swagger, yeah. Essentially swagger stuff, yeah. And they’re using swagger stuff to auto generate SDKs. And obviously there’s some pros and cons to that as well. So there are ways that companies are being creative to try and offer more options to their developers. But yeah, it’s a problem. For me it really comes down to the data of where developers are, what are they using? And we prioritize the ones that have the largest impact, I would say.

Allen: Yeah, I guess that the approach of auto generating 10 SDKs of languages that you don’t really yourselves use could be effective for some startup that’s trying to sell to enterprises that needs to check a bunch of boxes and then their sales team is like, “Oh, we need a Clojure SDK,” or it’s probably not going to be Clojure, but it’s like Java or.NET or whatever. ‘Cause someone’s still using ColdFusion and then it’s like, “Okay, well we can use this to generate.” And then we can say, “Yeah, we checked the box of a ColdFusion SDK.” But it’s going to be obviously documentation and the idiomatic, I don’t know what idiomatic ColdFusion is, but Idiomatic ColdFusion would have some way of taking the pieces of your API and presenting them in a way that was intuitive and appealing to the developers. And I guess if they’re using ColdFusion, they’re probably fairly tolerant to weirdness, that was a bad example. But I think that the approach that, it sounds like you’re taking where you have two or three Hero SDKs that you maintain to hopefully a really good developer experience. Hopefully it’s fairly idiomatic that the Python one feels a bit different than the Java one, and they’re not just the exact same Java API splatted into Python. It’s going to create more developer love, which it’s hard to measure that in dollars, but it’s something that I care about and I think tends to lead to better long-term outcomes when you’re trying to build an ecosystem.

Steve: I hundred percent agree. Yeah. And our three SDKs, I mean talking about being more specific to the language first, like being generic, so all three are easier to maintain. That’s also something that we have to take into account when we’re building these SDKs. So we try to have some shared principles between the three different languages, but for sure each one has to cater to their audience because if not, like the Java SDK, if it doesn’t feel Java-y, Java devs aren’t going to use it at the end of the day. So definitely some pros and some constraints to work within there.

Allen: We’ve hit that a few times, even just working across Swift and Kotlin building mobile apps, where the Swift team or the Kotlin team will have an exciting idea for a framework that they would like to… It also exists on the other platform ‘cause a lot of our team members work on both platforms. And those languages are quite similar. They’re a lot more similar than Python and Java are. But sometimes the Swift developers will be like, “Oh, there’ll be this really great thing. And we’ll just do things this way and it’ll just be magic.” And the Java dev or the Kotlin developers will either be like, “This is insane and totally backwards from our perspective,” or, “Kotlin already just has this feature automatically,” or, “This is basically impossible to implement on Kotlin.” And so you end up with this, the two people who feel like they’re talking the same language, but they’re very cross purposes sometimes when you get a really excited person on in one language, it doesn’t always translate.

Steve: It doesn’t always, no.

Allen: You mentioned Open Source as input and obviously Open Source is a excellent flywheel. Like what you were talking about, if you can have people at Open Source helping maintain your SDK is like, what a dream, right? You got enthusiastic enough developers and enough goodwill that they’re helping do that work for you. You mentioned Open Source as a way to get feedback. And obviously people file, they have issues and these kind of things on the SDKs. And this is maybe a bit of a product management question, but how do you split your attention in between the squeakiest wheels in GitHub versus all the people out there that are maybe not filing feedback? Are you going out and to outreach and sending product managers to go in and knock on people’s doors, metaphorically, knock on their inboxes and being like, “Hey, I noticed you tried this and you haven’t filed anything,” or whatever, and then merge those two streams? Or are you mostly being like, “Hey, can you please file a GitHub issue if you notice anything?” And then mostly using that as your input?

Steve: Yeah, I think for a successful product org, you have to have multiple streams of input. Some of it is just, GitHub is one stream for us, but we also have “/feedback” in Slack, which is another stream and developer related questions come in there. We have a community workspace for developers to hang out in. That is also another great avenue for feedback. It’s also just a great place for developers to bounce ideas off of each other and come up with intuitive solutions, that kind of thing. And through that, in that community workspace, we’ve also created a developer advisory board. So we have developers from a lot of our largest customers, who are building Slack apps, participate. It’s a form for us to share what’s coming in the roadmap, but also a form for us to collect what’s bothering them about the platform and what we can do better. You need all of these streams really to make sure that you’re not missing anything important. You don’t have these large product gaps in your offering. And the stuff you said about being proactive and reaching out to customers who maybe have created something and they looked like they were active for a minute and then they stopped, and maybe there’s a reason why they stopped. So we definitely try to keep track of that as well, especially with some of our largest customers, just to see what’s going on there. And yeah, you have to pull all of that together. I feel empathy for the product managers because it’s really their job at the end of the day to take all of this feedback, prioritize it, and get it on the roadmaps. For quite a while, my team, the tools team, developer relations toolings team, we were a little scrappy, so we didn’t have a ton of product input except for maybe the new features coming in. So it gave us time to really be responsive and reactive to the community. And example being like devs were constantly getting stuck trying to set up OAuth. OAuth is one of those classic tricky problems. It’s not that tricky, but it can be tricky and every company seems to implement OAuth a little differently, even though there’s like-

Allen: It’s just annoying and unpleasant and a lot of people don’t want to do it, so I can see why that would be a fall off point.

Steve: Yeah, yeah. And it’s one of those things that we’ve always had a lot of people creating issues for. And our GitHub, it’s not just people reporting bugs, it’s like people asking questions. It’s probably, like 90% of our-

Allen: “How to install the VS Code?”

Steve: Yeah. You get things like that. And you got to be empathetic to your community, and that’s a big part of it. If it’s a resource constraint, maybe we try to push them over. In Slack, we call it raccooning, like maybe there’s a different avenue that they could ask that question that might be better. But for the most part it’s not worth doing the raccooning. It’s better to just do a quick answer and give that developer a good experience right there.

Allen: This is very slightly dig into that for anyone of this thing about raccooning. I think I’ve seen this behavior before from my Michael Lopp who used to work at Slack. And he would respond in Slack with a raccoon emoji, which meant in a non-rude way, “This message doesn’t belong in this channel.” Is that the origin? Am I correctly conveying that slack isn’t…

Steve: That is correct? I don’t actually know where it started, and it’s just something that when I joined Slack and people started putting raccoons on messages, you just learn that that’s what it means. So usually, if they’re more helpful, it’s not just the raccoon, but there’s like a message in the thread telling you where to raccoon perhaps.

Allen: Yeah.

Steve: But yeah, that’s where it comes from.

Allen: Not to interrupt that, but I found that habit, that little trick, actually, it doesn’t matter as much at a really small company where everyone knows what channel goes where, but when you have a hundreds and thousands and tens of thousands of person org, it can be useful to have a non rude way or, I don’t know, slightly rude, that means non-zero amount of rudeness, but a low rudeness way of saying like, “Thanks for your message, but maybe not in the announcements channel or whatever.”

Steve: Luckily I haven’t seen anyone taking it negatively. We have this saying that like, “Assume positive intent.” So if someone’s putting a raccoon there, don’t assume that they’re annoyed at you. They’re actually trying to be helpful by telling you to go to the right channel with your question.

Allen: Yeah. At a 10,000-person company, or I don’t know exactly how big the… do you know how big the Slack org is these days?

Steve: You know what, I don’t. Because we used to have that information more visible pre-Salesforce acquisition. And I think we were around 2,500 or so around that point. We definitely had a bit of a hiring boom, I think, post acquisition. But things have obviously changed with the economy and the way it is right now. And we’ve had hiring freezes and Salesforce did layoffs. Yeah, in the thousands.

Allen: But you’re in the thousands, anyway. Enough that there’s at least one person in the org, not to demean your org, there’s at least one person who probably is rudely using raccoons and does not have positive intent. And it’s like, “I don’t want to see these messages from you anymore, Steve.” But it is a nice habit if you can just try to assume that even just by default people are being kind and helpful.

Steve: Yes, it helps.

Allen: And every once in a while a manager might need to step in and be like, “Hey, stop putting in these rude raccoons because I see you doing that.” So that was all an entire sidebar about how you were trying to describe something about building APIs, but I just had to dig in on this raccoon thing.

Steve: It was a good sidebar, a little bit about Slack’s culture internally. So OAuth is a great example of community struggling. We’ve written guides and stuff, but it’s only going so far to eventually we just decided to make it a first class citizen of our SDK and make it super simple for you to set up, like provide A, B, C, and we do the rest for you. Provide these three different parameters when you’re initiating your app and we’ll set up the routes for you and tell you what to go copy and paste into the config page and all of that type of stuff. So that was really well received by the community and we implemented it in all of our SDKs. And that’s the thing that doesn’t always end up on a product roadmap, but you see enough of it’s squeaky enough that you just have to spend some time, carve out that time to create the right solution, I think.

Allen: Well, those things really add up. If you don’t know what you’re building or why, then that’s just gold plating that you want to defer. But once you are getting some clear need and traction, that’s the kind of stuff that helped make Stripe into a many billion dollar company is, like, this is a company that if you tell your developer, “Hey, got to implement payments.” And they’re like, “Ugh.” Especially back 15 years ago when Stripe started. And then they go to the front page and it’s like a three line, paste in these three lines and it’s in a nicely formatted thing with the examples in different programming languages. And then suddenly they’re like, “Oh”. Stripe didn’t have to have a little UI like that, that had little paste copy paste things in different languages on the front page of the website. But they did, and they went hard on docs and all of that stuff and they ended up just completely blowing away the state of the art at that time, which was… I integrated a payment system about three or four years before Stripe came along and it was one of the most unpleasant things I’d ever had to do.

Steve: Sounds like OAuth.

Allen: Yeah, exactly. I’ve integrated OAuth a few times. The first time I hated it a lot. By the third time I was just like, “Why did I think this is so hard?” But it’s because it’s weird. So that brings me to like this. I know that you’ve been working on this large project. You’re in the middle incrementally shipping a rethink, or I don’t know if rethink is the word you would use, but a rethink, revamp, overhaul of the Slack APIs,, how people build apps in Slack. And I’d be curious to get a little bit of a framing for it, and I think a lot of folks who listen to the show probably have at least used it, but probably a lot of people that have been involved in maybe commissioning or building a Slack app. So what’s changing both at the low level? But then also what does that mean for people who are maybe going to build something? And how did that all come about? I’m asking you three questions at once.

Steve: Yeah. I’ll try my best to answer them all at once. So yeah, for a couple of years now, we’ve been working on the next generation of Slack’s platform. Slack previously you would build an app, it’s contained altogether. Apps don’t really interact with other apps. You could think about Google Calendar, you go to it, you’ll see your calendar, maybe you can create events, that kind of thing. That’d be like the max you could do, but there’s no way to have a message that you’re chatting with a coworker and they’re like, “Hey, let’s schedule a meeting.” And then maybe right in that thread you kick off a Google Calendar invite, and invites both people, and sets up a Zoom room, something like that. We’ve never really had this ability for apps to talk to other apps and bring all the different tools that you as a developer or as a knowledge worker or using into Slack. So this next generation of our platform, it’s all about automations and bringing in all of the tools you use outside of Slack into Slack and connect them in ways that make sense for your use case. So now instead of having developers build these standalone apps, we’re instead asking them to build functions. An example being we could have a function for Zoom that creates a new Zoom room, and you can have a function from GitHub to maybe create an issue. And what you can do is you can actually start tying these in for your specific use cases in workflows. And the first phase of, you mentioned we’re iteratively releasing it. Last month, we iteratively released the ability to create these automations, these workflows in code. So we’ve released a new SDK, we’ve released a new CLI tool. It allows you to create these workflows and add specific steps. We’ve started taking the Slack API and adding those as functions and steps that you can use as well. So you can create a step to send a message to a channel. And you can see how you can start tying these different functions and steps together to start automating. And the next iterative phase of our platform is to actually expose all of these steps and the creation of these workflows through our low code Workflow Builder tool. So we’ve already had Workflow Builder a part of Slack for quite a while. We’re working on the next version of it now. It’s a little buried in the Slack client. So when I talk about Workflow Builder people sometimes are like, “Oh, I didn’t even know this existed.” It exists, it’s there.

Allen: I mean there’s a lot of things in Slack now. And this is one of the curses of its own success that the number of features and the number of… like you can add more and more things, but then eventually it’s like, “Wait, where exactly where is what?” which is not. I don’t think a failure necessarily of just like a victim of its own feature fullness as almost all successful products ends up being as it’s own.

Steve: It’s true. And we’re always thinking about how to reorganize all the different features in Slack, and I’m sure there’s something up our sleeve here coming up soon.

Allen: No announcements.

Steve: No announcements right now, but with a new organizational structure there. But yeah, so Workflow Builder, it’s a tool that you can, once again, go in. You can see all the different integrations for all your favorite third-party services that you’re using, and you can integrate them in an order that makes sense for you. You can trigger them based on specific events. Like there’s Slack events, so people joining channels, people posting messages. They’re scheduled events, so like every day at 9:00 AM, post this to channel. Maybe it’s a daily standup, that kind of thing. And then there’s going to be third party events, so events that are happening in other people’s systems that you can use to trigger workflows as well. So we’ve been working on this for a few years now. We’re really close to shipping it, the entire end-to-end experience. It gave us an opportunity to really think about developer experience from the beginning, which was exciting. It’s not often you get to rethink about a platform. So we know from chatting with developers that hosting has always been a little cumbersome, setting up hosting for Slack developers. We know this going between your code and our app config page has been a point where people lose focus or get confused. So those are just two examples of things that we managed to actually solve because we had a chance to start over in a way. So instead of going to app config, we’ve brought your manifest and code. We’ve brought hosting natively in Slack now, so you can actually deploy your applications, these automations to Slack’s infrastructure. We’ve created data stores that you could use as well. So you don’t need to go spin up your own MySQL or MongoDB or whatever. So all of this we’re offering natively now in Slack for developers. And what used to take maybe 5 to 10 minutes to getting started and building something “Hello World-y” to little useful can now be done in a minute. As we’re continuing to do this, we originally are targeting TypeScript and the Deno runtime. For those of you who are unfamiliar with Deno, it’s like alternative to Node.js built by the same founder of Node.js, Ryan Dahl. And the big selling point for us was kind of, it’s secure by default nature. If you want to access the file system, you got to request it. It’s not something that’s just available to you. If you want to have your app interact with APIs outside of external APIs, you need to let Deno know in advance of what those APIs are. So those type of security features we’ve built natively into this new offering. And we’re hoping by having some of those available, that admins are going to be a lot more liberal when it comes to approving these because they can see like, “Hey, Steve is sending up a function to interact with Jira and it’s only accessing our Jira endpoint, so it’s probably a little safe for us to approve. There’s not much of an issue.”

Allen: Instead of the Slack app wants to read and write everything in all channels in your whole org at any frequency. And it’s like, “I don’t know if I love this.”

Steve: There’s definitely apps in our app directory that request all the scopes and they don’t get installed in a lot of workspaces.

Allen: Yeah. Well, it’s been interesting to me doing some research. I’ve been doing some product research of my own on different products we could build and integrations and research on, like, a thing I think a lot of people are doing right now and seeing like, “Okay, we have these cool large language models that can look at text and look at ways of analyzing it or generating things out of it.” And an interesting thing is to think, “Oh, well, what can a language model do if it can access your Slack?” But the interest of especially enterprises, but even medium types companies of being like, “Hey, do you want to improve my Slack app that can read and write everything and throw it all into a large language model?” is like, “Hmm, I’m like 99.9% skeptical of that.” So the idea of being able to scope things down and be more clear to the people who are approving these things, that’s a great thing for people trying to develop apps because you can build this amazing workflow that if it’s like, yes, if you could trust it with the keys to your everything. Because people put really sensitive things in Slack. People are a lot more, at least in the people that I’ve been talking to, are a lot more concerned about granting access to Slack than they are about granting access to GitHub, which I thought of, “Oh, well, GitHub, that’s your code.” They’re like, “Ah, whatever. It’s just code. Our strategic plans are in Slack.” People post private keys in Slack even though they shouldn’t, stuff goes in there.

Steve: Yeah, they shouldn’t.

Allen: So it’s cool that y’all are working on that. And it also sounds like this API would solve it. And tell me if this is true, but seeking to solve a problem that I’ve hit a lot as a consumer of Slack apps, which I’ll be like, “Oh, great, like a Zoom integration.” And so I’ll add a Zoom integration, and then it has some functionality but not the functionality I imagined it would have. So it’s like, “Oh, great, now you can go type ‘/Zoom start meeting’ to start a meeting. And I’m like, “Oh, okay, well, that’s fine.” But what I actually wanted is that when the meeting, that this Slack channel is for, is started, that you put a reminder or whatever, with whatever thing I had in mind. And the Zoom app developer just didn’t even think of that at all. And it’s like, “Okay, well I guess I could create an entire whole app from scratch that integrates with the Zoom APIs to do this, but then it’s way more left.” Whereas it sounds like you’re saying if there was a new version of the Zoom API or Zoom Slack app on this new system, they could just give us a bunch of primitives, like “start call”, “see calls in progress” or whatever. And then we could write, even host it on Slack infrastructure, so we wouldn’t even need a Heroku instance or anything. We could write a few lines of code maybe and be able to puppet Zoom to do things based on what our needs are.

Steve: Or you could do it in the Workflow Builder and not even need to write code.

Allen: Well, you know that I would just use the code because.

Steve: I know you would.

Allen: Maybe our product managers or PMs or other folks on the team would maybe like the workflow builder. So it’s nice to have that option too.

Steve: Yeah. You could set up a React, that if this React is put on, “invite everybody in this thread,” to a Zoom channel, a Zoom meeting and everyone can just go. Something like that. We’re very stoked about it. We’d love people to give it a shot. It is in TypeScript only, so I apologize to my Python devs out there for now, at least. And we were intentional about that. We’re really proud about all the different type of head support we’ve added in there. So hopefully it becomes pretty intuitive when you are using the SDK, what options are available for you and give you that type checking before you even try to deploy. And with the new CLI, when it comes to developing apps in the past, you’d always want to have a dev instance of your app and the prod instance, so you can hack on your dev instance freely. And then when you’re ready, you can push it to prod and deploy that out. With the Slack CLI, we’ve built that support in natively, so we give you the ability to do Slack run and it creates a dev instance of your app that you can deploy to Slack and start running and testing with and iterate it. You can live code, and those changes are immediately shown up in the client. All things that you expect as a developer these days, I think.

Allen: Well, “expect” isn’t always the right word, but like that you want there. Once you have this experience in one product, then suddenly it’s like, “Well, every other SDK is now broken until they catch up.”

Steve: Yeah, or you’re like, you’re setting all that up yourself with third-party libraries and it’s never consistent.

Allen: Well, there’s the one person on the team that sets all that stuff up, but then the eight other people just complain that it’s not as seamless as the other experiences they’ve had.

Steve: Exactly. Yeah. So with Slack CLI, we’re able to give you that second instance for free now. And that back and forth developer experience, you want of live coding seeing that live in the client itself. And then once you’re ready, you would just do the Slack deploy command, and there’s your production version live and available as well. And you could set who gets to see these things from only app collaborators to everybody in the company or specific users.

Allen: So I’m excited to see what people build on it. But before we run out of time though, there’s a question they want to ask. You’ve been building developer experiences for a long time now, and you’ve seen a lot of ways it can go. And you alluded to this a little bit at the beginning of the call, but I’d be interested to try to get an example from you of mistakes. It can be your mistakes, it can be some mistakes that you’ve seen others make, that you don’t have to blame names. But there’s a set of approaches and things that work well and don’t work well when you’re building developer tools that are fairly different in some ways than when you’re building consumer facing tools. Can you think of any most memorable or biggest or most lessons learned moments or mistakes that you’d be willing to share on the podcast?

Steve: Oh, man, that’s a tough question. I’m thinking of a recent one. Recent by within two years, I want to say. This type of thing has happened a few times in my career, but there was this feature that we were creating in Slack. I think it was called Easy Subscribe, something like that. I don’t want to call out the team or anything like that. But it had intentions of making it really easy for people to subscribe to events from third-party services. And I just remember it came to our doorstep pretty late in the product cycle. Sometimes things come early in the product cycle to us, in the SDK team, and we could think about the developer experience right off the get go, and what are the arguments people need, and “Oh, this is actually poorly designed.” Well, this one, it actually came to us a little late. It was already fleshed out. APIs were designed. And even if you were trying to use the APIs, it just felt clunky, unintuitive. You had this sense that like, “I don’t know who would really use this product feature.” Maybe the product feature itself was half baked a little bit. But if the idea was even sound, the implementation of using it was just not ready. It felt rushed. It felt like you just took a product spec and just worked your way to it without thinking about how developers would actually use this thing. And it made it to us. And I just remember thinking like, “Wow. We’re asking them to understand way too much about the inner workings of Slack if we want them to implement this.” Instead of like, you almost never want to expose your own internal implementation details when it comes to developers. You want to give them this-

Allen: Even though those details might seem totally obvious to all of you internally because you’re like, “Oh, of course everything runs on a flip because that’s just some jargon we have internally.”

Steve: Yeah. Yeah. And that’s something that I think, at least our DevRel team has been very intentional about, of like, “Let’s not expose implementation details externally. Let’s make sure what we provide developers is a good developer experience.” So that was one of those that, like, we added support, but we were pushing back the whole time. And it ended up not shipping because I think once we put it in beta, it was pretty obvious that people were not going to use this thing. It just wasn’t solving the problem the way that it was originally envisioned that it would solve the problem, which is sad. That happens. It’s like all this effort you put in. At the end of the day, I’m glad we can make a call to not ship something, too. That it’s not always easy. If you’ve spent months building something, and maybe it’s been in the works for a year. From the initial idea phase to all the product spec proposals, to tech spec proposals, to SDKs. There’s quite a journey that a feature takes before it gets into the hands of developers and users. So I’m glad that we’re not afraid to say “no” when something isn’t up to standard.

Allen: That’s a critical skill so many companies end up getting really… like that’s the beginning of the end for a lot of companies that get to a certain scale is when they lose the ability to say no. Like something we said, “We all said we were going to ship this.” Maybe some person in some layer of leadership has a KPI that shipping it successfully is part of their success or whatever. And so then there’s internal politics makes it get shipped, rather than taking the lens of like, “Is this something that is really serving our developers or our users or whatever.” So it’s good to hear that Slack still has that, or at least a couple of years ago still had that, but it sounds like still has that.

Steve: We still have it. We still definitely have it. And Slack internally we’ve got a lot of different processes in place to help hopefully catch this type of stuff early as well. We have a API advisory board, where as new APIs are coming out, they should go through the advisory board, so they get reviewed for consistency. Are they useful? Are they following standards in the external community as well? If we’re creating an API that other companies have created similar APIs for, are we using similar names and properties, that kind of thing. I participate on that board and sometimes it can be a little slow and tenuous getting into those almost bike shed-y sometimes conversations.

Allen: I mean, you’re asking programmers to debate about the format of things. You’re going to get some extreme bike shed tendencies unless you really tamp that down somehow.

Steve: Yeah. Yeah, and we do. We try to move forward at a pretty good pace in those type of groups because we don’t want to necessarily hold back work either that’s ready to ship.

Allen: Well, you want to hold back work that’s not ready to ship, so it’s like that fine balance.

Steve: It is a fine balance, yeah, but I find having a group like that, it’s really kept the standard high for what Slack releases. Just one of the many things Slack does internally to help keep the bar high. And I think Slack’s always had a high bar in terms of the end user experience, like what product features go out, how they’re organized. And we try to mimic that bar when it comes to developer experience as well.

Allen: I love it. Well, I think that’s a great place to leave it for now. Thanks, Steve. Where can people go to learn more about you and your work? Do you have an online presence that you might direct people to?

Steve: I mean, I used to tweet back in the day, not so much anymore.

Allen: Back when tweeting was a thing.

Steve: Back when tweeting was a thing. @stevesgill is my handles on Twitter. You can find me on LinkedIn. I guess that’s what people do these days. But really I’d say check out the work that we’re doing on api.slack.com. You can learn about our new platform, download our new SDK, our CLI. Give it a shot. And let us know what you think on GitHub or any of the other channels we have available.

Allen: Awesome. Well, I’ll link those up in the show notes. Thanks for being on the show. It’s been awesome. It Shipped That Way is brought to you by Steamclock Software. If you’re in a growing business and your customers need a really nice mobile app, get in touch with Steamclock. That’s it for today. You can give us feedback or rate the show by going to itshipped.fm or @itshippedfm on Twitter. Until next time. Keep shipping.