API-As-A-Business with Christine Spang of Nylas

Ledge: Welcome to the Frontier Podcast from Gun.io. I’m your host, Ledge. Today, SaaS companies rely more than ever upon core services and building blocks provided by other companies. And Nylas is one of those companies providing an API similar to Stripe or Twilio but, instead, focused on email, calendar, and context sync.

In this episode, I’m happy to welcome Christine Spang, co-founder and CTO of Nylas. Christine’s background is back in Python and systems engineering and she is a contributor to open source projects including Debian. She’s led the engineering team at Nylas since she founded the company in 2013 and Nylas is happy to announce that they recently just closed a $16-million-dollar Series B to expand their service.

Welcome, Christine! Congrats on the raise there!

Christine: Thank you so much. Thanks for inviting me on the podcast. It’s really great to be here.

Ledge: It’s so cool to have you. You and I got to brainstorm a little bit off-mike and we were talking about you as a CTO. Building a service, you have to decide which things are the core competencies of you and your team versus which things are not.

It’s kind of interesting because your service is the thing in which other CTOs are making that determination about themselves. You have upstream providers and there are downstream providers and that’s no longer just like a network engineering concern. It’s like “How do I know what to build and, essentially, what to lease from somebody else?”

How do you even to begin to put that together when you’re getting started?

Christine: It’s kind of interesting to take a step back and think about the history of computing and how we got here.

Back in the day, people used to build everything in-house. They would put a huge engineering team. It wasn’t really a question of “Am I going to buy this from somebody else?”

You’d have an operating system and then you’d just build all the software for whatever you’re trying to ship.

Then, that kind of came along. It’s like open source software where people started building and releasing these shared components that everyone could use and that built up this really big and great ecosystem of different components that people could take and use when building other things.

But we’re still essentially building things entirely in-house but often using kind of like shared components. If you went from one job to another, it’s like “Now, I used Apache at my last job and it was a pretty good web server so we’re going to use Apache again here.”

Being competent and skilled at essentially open source building blocks became something that you were expected to do.

And that’s still true today for engineers. There are so many key and core open source technologies that lots and lots of companies use to ship their software.

But the newer trend is not just having open source building blocks but also deciding when you’re going to use a SaaS service to provide some key components of what you’re building.

Especially for startups today, you only have so many resources and it’s really a good idea to keep your team small as long as you can until you actually figure out what you’re building, who your customers are, and what the features of your product should have.

And you’re kind of in scaling mode because having a smaller group people is so much for communication. It’s so much less complicated to get an idea back and forth and riff off things when you have like five people in the room rather than forty.

This all means that teams that are building software these days are actually shrinking. We’re building bigger things with fewer numbers of people.

Maybe an extreme example of this is if you look in the last few years when WhatsApp was acquired by Facebook for sixteen billion dollars. They had thirty-two engineers and hundreds of millions of users.

I think that’s like a bit of an extreme example and it’s not the average these days. But it just kind of shows how fewer number of engineers are accomplishing greater and greater things by being super focused.

WhatsApp is just like a messaging app. They don’t build anything else.

I think that determining what your core competency and what you’re just not going to focus on is really important because every hour of your engineering time, you spend building internal developer tools or deployment software or packaging or whatever. Anything that’s not your product is essentially engineering overhead.

You have management overhead which is what you need to run the company but there’s also engineering overhead where you’re building software that’s not the product that you’re selling. Then, you have to maintain that software and you also have to train people in that tool that is specific to your organization when they arrive.

I just think it’s important to be really careful because the more code that you have, the slower you’re going to move because maintaining code takes time. And there’s a lot of mental overhead in having to know how different systems work.

Ledge: And even when you’re consuming somebody else’s service and making it part of your own, you still incur that downstream technical debt. They’re going to update their service. They’re going to deprecate methods or there’s going to be a new version.

Do you think it’s still a net positive there where you simply don’t have to internalize that cost on your team?

Christine: I think you still need to think about tradeoffs and what you’re gaining versus what you’re not having to think about.

When you consume like a SaaS service, you’re replacing an internal engineering team with a vendor relationship. And that takes a different skill set to manage.

Building software is also a people problem but it’s definitely a different flavor of people problem in that you’re not going to be seeing these people every day. But you still need to be communicating about what your needs are especially for “Here’s Nylas for our biggest customers.”

We have like pretty strong relationships with them where we’re talking to folks from their teams on a weekly or every other weekly basis because we’re essentially building a technology that is a core part of what they ship and we need to almost function as a sub team of their company that has inputs and outputs.

So we need to communicate about things that we’re building or fixing that affect these folks; and they need to communicate with us as to what their priorities are ─ what’s the most important thing.

In some cases, we have companies that are using different parts of our product like different APIs on different teams so we’ve had to establish relationships with them where we figure out how they’re going to be communicating internally with all those teams and figuring out what the most important thing is and jumping on a call with us with all their relevant stakeholders in order to make sure that everyone knows what’s going on.

It’s a very similar to what you would do in a large organization which has an internal team that’s building a service and shipping it to the rest of the organization except these are two separate organizations which, I think, is a really interesting development.

Ledge: Yes. It’s like the boundaries between what we would have ─ just considered yours and mine and theirs and us and them. It’s all like sort of blurring around these ─ I think we call it the “macro services.”

It’s the same architecture but it’s an organization in sort of an abstracted level.

We’re all depending on Amazon and we’re all depending on Google. And there is so much stuff going on there and we have to trust them sort of implicitly that we’ll even have a business without those platforms.

And then, somewhere down the line, for your business, there’s a CRM. And if I can’t sync my email, that’s a pretty big deal and some sales guy is using their CRM is going, “Well, my email won’t sync” and the CRM is like “Yes. We use a provider for that.”

And the sales guy has never heard of Nylus and never wants to.

How does all that flow together? If you, guys, have an upstream provider that’s giving you trouble and then you have trouble and it flows down to your downstream customer, how does the trust and the communication and everything happen there?

Christine: This is something we think about all the time. I would say that we’ve made a lot of progress on making this problem better but we still have significant ways to go together to where we want to be.

I don’t know if you have heard of ─ I can’t remember what book it was but some book at Amazon that’s talking about how the way that they design their services is kind of self-service and it’s one of their guiding design principles.

For people using AWS, it’s like “I don’t want to talk to AWS support. Talking to AWS support is a huge pain in the ass. It takes a really long time. After we have to hold for a while, I have to explain to this person what my problem is and, sometimes, they don’t know what I’m talking about and it takes really a long time.”

The goal of AWS is to design their service in a way that I don’t actually ever have to talk to support. It’s definitely our goal at Nylas as well.

I think there are a few different components of that. Especially when you’re building developer tools, you almost want to be able to give people insight and visibility into the system to the same level that they would if they were building in-house because, as a trade-off, you don’t want people to have the face of “I want to build this in-house not because we could do it better but because I emotionally feel like I have more control over it and I can tell what’s going wrong and I don’t want my hands tied by some other party.”

I think it’s a huge challenge when you’re building this service. If you can achieve that and get it right, that is what makes your service really powerful.

There are a few different ways that we try to do this. One is by just kind of exposing all of the logs for the service through our developer dashboards so that you can see what’s happening in the inside.

Then, there’s also a challenge of making sure that those logs communicate well to people who are not familiar with your codebase.

I think it is tricky and it’s all about communication and you both need to be able to document well as to what the capabilities for your system are but also what the failure modes are.

If there’s something going wrong, it’s for someone to be able to take an action by themselves in order to resolve it. And there’s definitely a lot of room for us to improve in that area right now but we are kind of making progress on a month to month which is pretty exciting.

Ledge: I think it’s an underrepresented budgeting item to think about the customer experience of your error log or things like that.

Christine: It’s like whoever wrote these log messages was not originally expecting them to be customer facing. But they are when you’re a developer tool and I think it’s a little bit of an iterative process especially when you’re trying to improve the introspection capabilities of you end-user developers that, “Okay, we’re not going to fix all of this information first but let’s first expose and see what people run into these problems or what’s weird and then iteratively improve it from there.”

Ledge: You’re totally in line with a lot of the people I’ve been talking to as we produce these episodes. It’s just like the coalescing of engineering and product. It’s just so palpable now.

Engineers need to think about customer empathy. That was not the thing even three or four years ago. And that keeps coming up again and again that “Wow, we need to break down those perceived silos between product and engineering.” It’s not enough just to build now.

Christine: I think there are a lot of different ways between the engineer today versus the engineer ten years ago. He or she is a much more well-rounded human being and person and who has to do a lot more things.

But, at the same time, we’ve built up all these building blocks and obstructions such that like you can be a really effective and powerful engineer without having to spend a few years to really deepen the guts of something because you’re building it from the ground up which is really interesting.

You can be a full stack engineer with a little bit of product and a little bit of design and there is also this kind of breaking down of silos between development and operations where we expect engineers to be software owners instead of building new features and throwing them over the fence to some sort of apps team who is going to care and feed them while they’re in production.

I feel like there’s a much better understanding of the fact that if you don’t understand the production part of your software life cycle, then you’re just like not a full engineer.

You can’t just build something because so much of that expense and cost and most of building software is actually like changing software that already exists in the wild and you need to be able to understand how to do that in order to be really an effective engineer.

Ledge: As is primarily dominated by development and spends very little time in production like things are backwards. It’s not the return of that investment.

Yes. It makes a lot of sense. I’ve also heard a lot of people talking about how development is moving left into Ops and security is moving left into Ops. And Ops is sort of like “Yes, you know the full stack is DevOps” and then you have developers but we’re getting a little further away from design and the front end people and it’s just this weird shifting where things are moving so fast and you need to know all the things which is

Christine: I think a really key part of thriving in the software world right now is just like loving and learning all the time because if you don’t like learning something new every day and you’re an engineer, you’re going to burn out so fast because the industry is changing so fast.

As you’ve said, it’s not just like learning the next new technology. It’s also adapting to the changing ways that software engineering organizations are run and the different kinds of skill sets.

In some ways, there’s like a little bit less specialization going on but it kind of depends on what you’re building. If you’re an organization that’s building web system, less specializations. And then, there are new areas of technology that are, perhaps, more specialized and they didn’t exist ten or twenty years ago and it’s like kind of a combination between research and.

Ledge: I agree. I was researching the genesis of the term “data scientist.” That’s pretty interesting.

So this will be my last topic and a little bit self-serving. I’ll apologize. When you and I were doing some brainstorming on topics, we talked about how, on the software side, it used to be a lot of bias against.

We’ve got to do all these things ourselves. We need to own everything ─ the tooling ─ and we know that things are moving the other way now. In fact, that specialization is important.

I brought up that, a lot of times, as a business that’s placing high-end freelance engineers, we get a lot of “not hired here. I want to my own employees. I must have full time. I must have dedicated ─”

And I just wondered, as a CTO, what do you think about that? Do you see that changing?

We talked about the boundaries around work that are changing. You can consume an entire team from somebody else on lease but there’s still a weird thing about maybe, sometimes, consuming one person on lease.

How does that suit you?

Christine: Maybe a little background context would help. So how long are you placing engineers at companies? Are they short-term gigs or long-term gigs?

These are freelancers but ─

Ledge: As long as the customer wants ─ in the context of our business, we’re really talking about long-term engagements. They can be half time; they can be full time. These people work for you.

I think there’s a little bit of a misconception probably in the freelancer space, in general, that freelancing came to mean “fly by night” or “moonlighting and kind of flaky, “MacBook on the beach” kind of stuff.

We’re looking at a cohort of individuals who are different so it’s definitely part of the messaging.

Christine: From my point of view as an engineering leader, the primary thing that I am thinking about and worried about as to how to form a team is the fact that I need to create a team that feels a strong sense of ownership over the product.

I personally don’t really care what the legal designation is of how we’re paying somebody. For example, at Nylus, we have mostly full-time engineers who are based in North America as kind of like the core of our team. But we also work with folks who are basically with a long-term contract whom we’ve been working with for over three years at this point. They’re basically database experts and they’re basically a part of our team.

But the way things work more in the database world is that you have to have multiple clients because it’s like a more specialized skill.

So they’re technically paid as contractors because they’re like international and they have their own little company and it’s so much easier for us to deal with that legally and also because they have multiple clients and we’re okay with that.

In that case, I guess, technically, those folks are freelancers but I feel like they’re a strong part of the team. They have a sense of ownership over the components that they’re responsible for. And, therefore, that’s essentially an in-house capability for us.

I don’t really care what it looks like on the balance sheet. Maybe our accountants care a lot more than I do. But, to me, it’s like, “Well, this is like head count; these are contractors. That’s almost the same budget.”

But it’s a little bit different when thinking about shorter term contracts. We actually worked with a shorter term contractor on a project last winter which was really useful to the company.

The things that go through my head when I’m thinking about reengaging with that contractor are mostly like ─ one, I want to be really cautious about having someone who is like in and out, like building core pieces of our technology because the fact of the matter is that when you build something yourself, you become like more of an expert in that thing than anybody else.

And no matter how much you modify something and work on it later or talk to that person, it’s hard to compete with actually having built it in terms of expertise.

So I’m cautious about giving somebody who doesn’t have a strong ownership over the product that expertise because it makes the team weaker.

Does that make sense?

Ledge: Absolutely! I think that’s absolutely right for core intellectual property and core competency. You really do want to have people who are close.

And, yes, we’re all looking at the same statistics where the average tenure of an engineer now is dropping to fifteen months.

Christine: I could talk your ear off about that if you want. I think modern software companies are also pretty bad at management and retention. I think that’s a solvable problem that is somewhat different but, I guess, it is something that you have to be cognizant of as an organization.

Certainly here at Nylus, we aim to be a place that you want to stick around for more than two years because it is really difficult to train people up. If it takes someone six months to get fully up to speed on your system, and then they’re gone in two years, you’re essentially spending thirty percent of their salary or whatever training all the time which is a huge amount of overhead.

Ledge: I love that thought: We’ll be a place that people want to stick around.

Christine: Yes.

Ledge: Christine, it’s awesome spending time with you. Obviously, you have big engineering things to go do. So we’ll respect your schedule.

Best of luck after that awesome raise and in doubling and tripling the customer count! Looking forward to consuming the product.

Christine: I appreciate it. Lots of fun challenges to tackle on all fronts both at the engineering level ─ and I certainly am learning a lot about growing organizations and building healthy places to work.

I can’t complain. It’s super fun and I’m excited to keep working on this.