Building APIs at Sendgrid

Speaker 1: I see a few familiar faces, a lot of familiar faces actually, from around the community, but also some specifically from DevRelCon London. Who was here in DevRelCon London? Awesome. So DevRelCon London was was a fantastic event. There's videos of the talks.

Speaker 1: If you haven't seen them, I definitely recommend you go check them out. Smart people just like this sharing knowledge. It was a great event. At DevRelCon London, I spoke about burnout, and it was a very well researched, rehearsed sort of presentation. This is the opposite of that, hence why I don't have slides.

Speaker 1: I actually initially submitted a topic to this conference to talk about the history of evangelism. Seeing the great talk this morning, I understand why I was asked to speak about API strategy instead, API design. And so API design is something that I started writing talks for multiple times to prepare for this event. And in the course of preparing for this event, I kept struggling with what I actually wanted to share and how I could deliver value about that topic to a room full of developer relations professionals who may not necessarily be working on API design. So I ended up kind of focusing on the practitioner aspect and sharing knowledge.

Speaker 1: I've been at SendGrid for almost five years now. And over the course of that, I've been in charge of our documentation, all of it, the whole thing, all of our SDKs. We have seven officially supported languages now. I was the interim product manager for our API for six months, mostly because I wouldn't shut up about how we needed to improve our API. So they said, okay, fine.

Speaker 1: Go work on it. And in the course of preparing for this talk, the conclusion I came to startled me because if I went back in time three years ago, it's never something I would say. But API design is less important than you think it is. The actual structure and how it works matters less to the success of your business than you probably think it is when you're starting to work on that product. And I have a bunch of honest open lessons, things we've done wrong at SendGrid, things that will make you probably very surprised at our success in spite of some of these failures.

Speaker 1: So what I liked about the talk I gave at DevRelCon London was that it was very open and honest and direct. And so I'm trying to bring that same energy here, that honesty, that openness, but bear with me if it's a little raw. So APIs have always been central to SendGrid. SendGrid's original name as a company was SMTP API. That was literally the name of the business.

Speaker 1: And when the company got accepted into Techstars, they immediately got made fun of for that name. SMT Poppy was a common nickname or Smiddapi or, you know, terrible name. But it gets the point of what you're trying to do across. Right? It's an API for SMTP interactions.

Speaker 1: Went through Techstars, renamed the company to SendGrid, learned a bunch of stuff, hit product market fit pretty quickly because not many people were doing outbound email in the cloud at that point. So the strength of our product market fit really made a lot of our poor API design decisions irrelevant in the face of the marketplace. And some examples of things that we maybe used to do, like when I started at SendGrid almost five years ago, you could actually make an API request to send email over plain HTTP with your credentials in the query string. Right? That's not great.

Speaker 1: Probably should have seriously harmed our business in a lot of ways. But I think because of the value proposition of the company, of how obvious it was to developers that they could add value to their app by using our product, they were willing to overlook a lot of these issues. We used to have an endpoint where the default mode, where if you didn't specify certain parameters, This was a delete endpoint for I say that. I mean it was delete as in CRUD delete. Obviously it wasn't actually a delete because everything was just a post request at that point.

Speaker 1: No other HTTP methods. But if you didn't specify which ID to delete, we just deleted everything. That was the default mode of this endpoint. I don't even know how long that existed before we realized it. So I can only imagine the frustration some of our users had when found out that they had just deleted an entire table's worth of data.

Speaker 1: We used to, on one of our webhooks, we would pass a content type of application JSON. But it wasn't actually application JSON. It was one complete JSON object per line. So if you were using something like Rails out of the box that looks at the application JSON content type and says, oh, I know how to handle that, well, now you have to start going to play around with Rails plumbing. One So of the key points I want to make sharing some of these examples is that you should not be afraid to get on stage and advocate a product that you believe is imperfect.

Speaker 1: And I know, Grace said in her talk that you should have passion and feel that your product is the best solution for developers in order to effectively evangelize that. And I agree with that. But I would say, especially if you're earlier stage, that you should have passion and belief that you can become the best solution for developers. And that can also be enough. You don't necessarily have to be there already.

Speaker 1: And that's hard because when your product's imperfect, you have to deal with a lot of criticism when you're out meeting developers. For all of the people who signed up and used SendGrid in spite of the fact that we were using plain HTTP, there were a lot of people who were like, what are you guys doing? How can I trust you to send email if you can't even properly secure your API endpoints? And that's a totally valid point. So how do you deal with with some of that criticism?

Speaker 1: For me, there's there's a few things that I've learned. A lot of these are sort of similar to the filters that Tim Falls mentioned earlier in his talk. But you have to be honest. You can't try and dance around the issue and say, oh, no, that's not a problem, hand wavy things. Don't worry about that.

Speaker 1: Developers have pretty strong, bullshit detectors, as everyone here knows, and they'll call you out. Be genuine, right? That's part of being honest. But when you receive bad feedback, chances are that you, as the evangelist for the product, know about all of those pain points already. And you probably feel them more deeply than anyone else.

Speaker 1: There's a chance that if a new position or you haven't been at the company very long, that may not necessarily be true. But that is good because that means that you can have empathy for your users, the people who are experiencing the problems, the things that are making your product maybe not great from an API design standpoint. And then be helpful. Right? Tell them if there's potential workarounds, how they can implement those workarounds.

Speaker 1: And then tell them that you're going to try and make it better. And the key thing there is to actually go and try and make it better after you tell them that. So part of this is to say, don't prematurely optimize. Right? Don't spend a bunch of time upfront trying to perfect your API design and make it truly restful and speak hypermedia and all of these things that you as a developer think are super cool and that all of everyone's gonna love.

Speaker 1: If you spend time building all of that stuff up front and without actually validating if your product is useful or if there's a market for it, you're just wasting time. Better to release a poorly designed API that delivers value than a great designed API for a product that has a questionable value proposition. Similar to a comment saying that if you're not embarrassed when you launch a thing, you've waited too long, that's very true. And you see that all the time with billboard websites and UIs. But you don't see that very much with APIs for several reasons.

Speaker 1: They're harder to do. They're harder to see the flaws in from a distance, especially if you're not a developer yourself. But don't be afraid to release something that you're not necessarily proud of or that you don't think is perfect. And get up on stage and tell people about how awesome it is or how awesome it's going to be. That said, just because you shouldn't optimize for those things right away, you have to optimize for them eventually.

Speaker 1: We still would not be around as a company if we had open API endpoints that were unencrypted. So one of the things that I've learned in in the last five years, and I know that this is my experience and that experience at different sized companies, vastly different, But you have to build a very, very strong bridge between the product side of your organization and your evangelists so that when your evangelists are out in the field hearing these pain points, they can actually get actionable work done to address those problems on the product side. Sometimes that's difficult, but work tirelessly to try and build that bridge if you have to. I talked to few people that I've worked with in the past. I'm very privileged to have worked with people like Adam Duvander and Tim Falls and Kunal Bachas attending.

Speaker 1: And so I asked them this morning, what are some of the things that you've learned about the intersection of product and evangelism that you think are worth sharing? And it was very interesting that pretty much everyone said that communication between those teams is is one of the most important things. Adam Duvander says that he used to have, at orchestrate.io before the acquisition, a weekly stand up where they shared their feedback from their team with with everyone at the company, which is a a 15 person company. Right? So it's very easy to have direct access to the engineers and to the product people.

Speaker 1: I think that's and and going going along with the the phrase that Adam has tattooed somewhere on his body about sharing knowledge, not features. Yeah. Right there. Awesome. And also to Guy Kawasaki's thing about sell the dream.

Speaker 1: You don't sell your API design. Right? You sell the value of your product. And that can be different if you're building a multisided platform or or whatever. There's different types of value.

Speaker 1: But for most people, you're selling something that can be achieved through your product and not the actual interface. I also think that having an API strategy early on is far more important than having a good API design early on. A lot of people jump into building an API and getting ready to release it without understanding how many dependencies that's going to create within their organization. Who's going to write the documentation for the API? Who's going to support it from ops to make sure it's running?

Speaker 1: Who's going to scale it when you suddenly have 10x account sign ups than you're used to? Who is going to provide support? Is your support staff going to be trained up enough to actually deliver value to customers who run into problems with this? How are you going to monitor your API to make sure that your latency stays within limits that you're happy with. How are you going to create runbooks for your SREs to handle things when API servers are crashing?

Speaker 1: Doing all of that right delivers more value to most customers than having a truly RESTful API. A lot of people don't even begin to think about the API strategy side of things and how they're going to support the thing they're releasing until they've already released it and grown it. So having strong people on your team, strong evangelists, strong community managers, strong support agents, strong account executives can make up for some pretty significant gaps in your product. And I've experienced this firsthand. We had one and a half year period at SendGrid where we did not release a single customer facing feature.

Speaker 1: A year and a half. Right? That's pretty long time, especially when people are used to getting app updates from Slack with change logs every week. Right? We we didn't release anything because we had gotten so much traction via the strength of the product that we were focused purely on scaling the pipe, making sure that all the email could continue to flow.

Speaker 1: And that was a good investment, but it made our job as evangelists very, very hard because it's hard to go out in the field and hear, you guys haven't released a new feature in over a year. Here's the list of things that are broken. What are you doing over there? All you can say is, we're working really hard to to improve things, and I'm here to make sure that you have a good experience with SendGrid. We have a good relationship.

Speaker 1: Let's keep that, and I'll keep you in the loop as as things improve and things change. I don't think that a strong product can make up for weaknesses or gaps in your people. Right? It it it works one way but not the other. And that's going back to what Tim Falls was saying earlier.

Speaker 1: Focusing on on the human aspect can can help you survive the times where you have when your service goes down and you have an outage, when there's a crisis, when there's a feature that's delivered a quarter later than you told people it was coming. So early early at SendGrid, community building is is the job of of the team that I run, the community development team. But for the first three or four years of that team's existence, we were really justifying our existence by the product work we were doing, which was SDKs, APIs, documentation. And we did a lot of work to instrument those things so we could track the value of the SDKs. And last month, we sent over 3,000,000,000 requests from the SDKs, so really happy about that.

Speaker 1: Last week, we had our first day where we sent over a billion emails. So I'm glad that we spent the time investing in scaling the infrastructure and the product. We still have work to do on the API side. I'm I'm really happy about the progress we've made. But for example, our core endpoint for sending email, which is the one that gets the most use, still takes a multipart MIME payload.

Speaker 1: It's not even JSON. Except for there's one parameter in there that you have to encode as JSON and then put in the multipart post. Right? So we still have plenty of of things to to do to improve, but it hasn't affected how quickly our business has grown. And yeah, we have developers who are like, wow, you're making this a little harder than it ought to be.

Speaker 1: But they stop caring about that when their email gets delivered and they don't have any problems with the service. If I could go back three or four years at SendGrid and change a few things about how we planned APIs, first off, I would make sure that we started talking about API strategy and how we're going to support the API rather than how we're going to design the API and how it's actually going to be implemented. One of the problems we ran into, because the company started with the API at its core so much that the company was named after the API, was that as the company grew and evolved, because the API was the product, everyone at the start had owned it. Everyone was contributing to that product, which is fine when you have 15 people. But if you continue to scale the organization and don't make someone accountable and say, you are in charge of the API, the API is your product, you you lose the accountability.

Speaker 1: No one is when everyone owns something, no one owns it. So I would make sure that we had a very clear person advocating for the API internally. I would push for API first everything, SOA, build build API endpoints for everything internally. And I would also build our developer relations team with a stronger emphasis on the human side of things, on the softer skills. Very early on, we started with everyone on the team was a developer evangelist.

Speaker 1: Now it's about 50% evangelists and 50% community managers. Part of that is because we've moved upmarket out of just APIs for transactional email. Now we have marketing campaigns tool that we launched at the December that's more like a Mailchimp style tool. So we now have to go evangelize our product to not just developers, but to marketing managers or startup CEOs or founders or people who are trying to build an email list and come up with an email content strategy. And that's a different role for us than gathering product feedback and helping people navigate use cases and the API endpoints.

Speaker 1: And I would also start having conversations with important decision makers earlier on about APIs in general, With the exception of Twilio, because I know Jeffy still gets up in live codes now and again, how many people here have a CEO who they think could look at API reference docs and be like, yeah, that's a good API? All right. That's that's a lot of you, and that's awesome. And you should definitely be happy that that's the case for you. Take advantage of that fact.

Speaker 1: At SendGrid, once the founders sort of brought on new leadership to take the company to the next level, we lost that. Now we have execs who understand APIs, and we can show them the value of APIs. But the API is essentially invisible to them. It's not like a UI where you get Marissa Meyer helping redesign logos because, oh, I can see that. I can play with it.

Speaker 1: I can make that change and see it right away. It doesn't work that way for APIs. But at least for us, that's the API, that interface versus the user interface, is what actually generates the revenue. So I would go back and make sure that I actually sat down with our leadership and helped them use our API. I think that SendGrid has been very successful.

Speaker 1: We're going to be profitable next quarter. We're growing very, very quickly. Just had a bunch of milestones. I think that if we had thought a little bit more about these things earlier on, we'd be farther along than we are. So I guess my my key takeaways here are that if you don't have a strong market for your product, then it doesn't matter how well designed your API is.

Speaker 1: And that sounds a little silly now that I'm saying it because nothing else matters if your product isn't strong. But sort of like the, oh, in 2000, wherever it's like, oh, we need a website. And as Grace was saying, oh, everyone needs an API. You might not. Don't build one just because.

Speaker 1: And that human humans, evangelists, us, this community, can make up for so many deficiencies in your product. It's not fun, and it sucks to get up on stage and be a punching bag when things aren't great with your product. The very first time I got up and gave a a talk at API Hack Day almost five years ago, I got heckled by an audience member whose emails were going to spam. Very first time I'd ever demoed the product. But I was able to go have a conversation with them after the demo and make them a believer, and TimeHop still sends their emails through SendGrid.

Speaker 1: It was called Foursquare and seven years ago back then, which is interesting. So yeah. And and again, surprises me to say it right now, but API design, not as important as you think. So thank you.