Building And Growing Nylas with Christine Spang

Hello, and welcome to podcast.init,

the podcast about Python and the people who make it great.

When you're ready to launch your next app, you'll need somewhere to deploy it, so check out Linode. With private networking, shared block storage, node balancers, and a 200 gigabit network, all controlled by a brand new API, you've got everything you need to scale.

Go to podcastinit.com/linode

to get a $20 credit and launch a new server in under a minute. Finding a bug in production is never a fun experience, especially when your users find it first.

Air Brake error monitoring ensures that you'll always be the first to know so you can deploy a fix before anyone is impacted.

With open source agents for Python 23, it's easy to get started, and the automatic aggregations,

contextual information, and deployment tracking ensure that you don't waste time pinpointing what went wrong.

Go to podcast in it.com/

airbreak today to sign up and get your 1st 30 days free and 50% off 3 months of the start up plan.

To get worry free releases, download Go CD, the open source continuous delivery server built by Thoughtworks. You can use their pipeline modeling and value stream app to build, control, and monitor every step from commit to deployment in 1 place.

And with our new Kubernetes integration, it's even easier to deploy and scale your build agents.

Go to podcastinit.com/

gocd to learn more about their professional support services and enterprise add ons.

And visit the site at podcastin it.com to subscribe to the show, sign up for the newsletter, and read the show notes.

Your host as usual is Tobias Macy. And today, I'm interviewing Christine Spang about Nylas into the modern era of email. So, Christine, could you start by introducing yourself?

Sure. My name is Christine, and I am the cofounder and CTO of Nylas.

A little bit about myself, I guess, kind of before that, I went to college at MIT. I worked a little bit at a kernel startup called ksplice, which was started by some friends of mine,

who I met at the MIT Computer Club.

And then about 4 and a half years ago, I started this company called Nylas.

And do you remember how you first got introduced to Python?

Yeah. For sure.

So I basically

got

into kind of, like,

computing and, like, programming in high school through basically through,

working with free and open source software. So

I

started contributing to Debian Linux when I was in high school,

and I started to teach myself Python for the first time as a part of wanting to contribute to Debian.

So I wanted to, like, work on some package that was written in Python. So

I, you know, found some online tutorials and started teaching myself Python,

that way. And then at MIT,

I was a class of 2010,

and

they were basically, like, transitioning their computer science curriculum at that time. So I was, like, the in between year where they had a new curriculum where kind of the introductory courses were in Python and an old curriculum where all of the introductory courses were in Lisp. So I kind of took a little bit of both.

So I got a chance to use Python a bunch in college as well.

And you mentioned that a few years ago, you helped to found the Nylas company. So I'm wondering if you can just explain a bit about what it is that Nylas does and some of the history of getting it off the ground.

Yeah. For sure. So

Nylas is basically a modern rest API that makes it really easy for developers to plug email, contacts, and calendar into any application.

So the idea for the company

came from

actually, my cofounder, who's a friend of mine from college, was

trying to build,

basically, some kind of, like, new products and experiences that worked with email and

as a part of his undergraduate thesis. And

he basically found that he spent several months just trying to actually, like, pull the data out and display it because all of the kind of technology to integrate with email,

was very complicated.

So

kind of the thesis was that 1 of the reasons that people haven't been building a lot of new things that have been really taking off, and making it easier to work with email is that because it is so difficult to develop with.

So what we took out of that was basically that we needed to make it easier to work with email so that people could be able to, like, experiment and innovate with, like, kind of the ways that you're able to use it.

So that's how we ended up basically kind of building this,

kind of server infrastructure and API that

abstracts away 50 years of email,

history and makes it so that you can work with email using the modern developer tools,

that people expect these days. And email

as a protocol and a means of communication has been around for a number of years, and its death has been predicted time and again, but it continues to maintain relevance and stay as 1 of the primary means of getting in touch and maintaining lines of communication. So I'm wondering if you have any theories as to what has made it so resilient in the face of so many different new protocols and means of discussion in that have been developed in recent years?

I think there's a few things that contribute to this.

1 is that by nature,

email

is distributed.

So

at this point, there are,

millions of servers out there that

help people connect to the email network.

And if you have your email hosted at any 1 provider, you can talk to anyone at any other email provider.

And I think that this property has been a key reason why,

email has become kind of so sticky and such a a key facet of how modern business communication works. There's no other system out there that essentially is

is an open network that

doesn't require everyone to be on the same system.

So all of these new systems that people have been kind of touting as email killers throughout the throughout the years

lose this key property of email.

And because there's so much infrastructure out there that kind of keeps the email network going,

it's hard to replace that.

And also a lot of the systems that are trying to unseat email as the main means of communication are largely

more synchronous in nature, whereas the async aspect of email makes it more beneficial to business communications and more thoughtful discourse because you are able to take the time to

write the message that you wanna write and ensure that you don't have any sort of grammatical errors or and make sure that you're including all the different talking points that you want. Whereas things like IRC or Slack encourage a much more rapid fire communication, which is great when you're

doing real time interaction with people. But when you want to have a more thoughtful and reasoned discourse, email is a much better

method of doing that because of that lack of urgency. I'm with you on that. And 1 of the early product offerings that you built at Nylas was the n 1 male client, which was very popular at the time that you first launched it and a little while after that. And I don't remember the exact timeline, but

you decided to actually sunset that project, which is now living on in a couple of open source iterations. But I'm wondering

what the wondering if you can share some of the lessons that you learned

from the process of building that client and integrating it with your platform

and how that has informed your current focus and where you're spending your energies right now.

I think that n 1 was a really useful product for us really stress testing our API in the early days.

And helped to kinda have a super heavyweight client that basically did all of the things in order to kind of really make sure that our API worked for any sort of client that you might wanna build.

And for that reason, I think it was totally worthwhile for us to have built it.

We kind of had the thesis in that day that I mean, we were experimenting on kind of what an email platform for the future might look like. So the first thing we built was kind of this data API,

and that was kind of 1 iteration

of what the future of email as a platform might look like.

The second thing we built was this email client, which was an experiment in, hey. Maybe people might want to instead of having to build entire applications,

build kind of, like, really powerful plug ins into, like, an email client that is built for extensibility.

And

our experience was that

and I think it's still possible that this kind of, like, vision might be a thing that could work someday, but it didn't work in this iteration for,

a number of reasons.

1 is just kind of like having a split focus as a company where,

you know, we're a small team or a start up and having kind of 2 major products,

was really difficult to support from an engineering standpoint. Definitely caused a lot of kind of tension internally as to, like, where we were spending our resources because,

you know, n 1 essentially, like, required

the API

to

to work,

and yet it also required a very different skill set for folks to be kind of successful at working on it. So it's hard for people to work on it on both parts at the same time and

also just hard for us to, like, resource each project appropriately with a small team.

So that was 1 thing.

1 another thing was basically that

we we found it very difficult to, honestly, to make enough money to make up for the cost of n 1

just through selling the email client. We essentially had this, like, longer term vision where we were gonna, like, build,

kind of plug in packages on top of n 1. And

those would be the products that people would kinda be using

at the end.

But when you think about it and you're also kind of already dealing with a constrained team, then you have 3 things. 1 is

an API infrastructure, which in itself is, like, pretty complex.

2nd is, like, this base email client, which is, you know, a,

an extensible system. And the third is, like, these kind of plug in packages.

So that's a lot of stuff to support. And, honestly, we just didn't really have,

kind of the size of team and time necessary to kind of build that into

successful business even if even if it had looked promising as to how we could kind of charge for it. For base email clients, people just don't expect to pay for them these days, so it's very hard to make money just selling an email client.

And

the

business

of Nihilus,

looking at the about pages and the fact that you've open sourced your employee handbook and some of the

blog posts that you've written has a very strong focus on encouraging diversity

and a very open

nature of the company. So I'm wondering if you can speak a bit to

some of the ways that you encourage that type of environment and how it manifests at work and some of the challenges that you've had to overcome to ensure that that aspect of the company

is continued as you add new people and the culture shifts with the inclusion of new people and the different dynamics that they bring to the table?

This is super important. For me, personally,

diversity inclusion is incredibly

important,

and I came to it because,

you know, I am a woman in tech. And

my my experience throughout the years has been generally very positive in the industry.

But I know a lot of people, and I also know that I've been really lucky

and

that kind of being early career, you also, like, don't see some of the, like, roadblocks,

that people tend to see later on where they stop getting promoted. So it's important to me as

part of starting a new organization from scratch that we really

do our best to create an environment where

all sorts of different people can be successful, not just kind of the status quo of what's worked in the past. There's a few things that we've done to,

kind of work on that. 1 is

is just like having a female founder helps attract kind of different sorts of people to the company,

especially for especially because I am highly technical. Few things that we do to kind of, like,

kind of propagate the culture. 1 thing I think that we got right from the get go was creating a core team that really also values diversity and inclusion.

And

it's important

to have buy in from the team because

these sorts of things take actual work. And if people aren't excited about working them and think that they're important, then they're just not actually gonna work on it. And it also takes a lot of work on

on oneself personally, kind of examining one's own biases and

doing things to address them.

So it's really important that the team thinks that diversity and inclusion are important things to work on. Otherwise,

you're kind of fighting an uphill battle. But once you do have that in place, it's much easier for

to kind of grow the team because

your team who's on your interview panels will help kind of find people who also kind of buy into this overall,

value. We

try to ask everyone who goes through our interview circuits,

you know, what they think about kind of diversity inclusion and make sure that they buy into it. We also

work with some organizations

that are kind of, like, training new folks, from different backgrounds and getting them into the tech tech industry.

1 organization we've been working with, is called Hackbright, which is

coding school for women.

Another organization that we just recently started working with,

our VP of engineering mentored for them last summer, and this summer we have an intern joining us joining our team is this organization called Code 2040 which is, kind of helping Black and Latinx

college students. So those organizations are really great. Trying to think of what else that we kind of do specifically.

I try to spend more of my time, kind of recruiting and doing outreach

to women and underrepresented minorities just because,

you know, it's sometimes

it can be harder to to find people who are not the status quo.

So you have to invest the time.

And I'm really excited to kind of connect with more folks from from different backgrounds, so I'm very happy to spend the time.

And 1 of the things that can

serve as either a deterrent or an attractor for people who don't necessarily fit the

standard stereotype

of a developer

is the way that the job descriptions are written because if there is too much of the alphabet soup or a laundry list of requirements, then it can often discourage people who might not feel that they're,

immediately qualified for the role whereas with a little bit of coaching, they could very easily grow into it. So I don't know if you put any special effort into the way that you

write your job requirements or your,

job postings when you are trying to hire for new positions.

Yeah. That's definitely

a factor. Factor. We've used this tool called Text IO to look at our job descriptions.

We've also spent a fair amount of effort just kind of, like, writing down and describing our culture, which I think by its nature,

appeals to

a wide variety of folks, particularly because we're a very collaborative team. It's not so much a place where folks kind of

go off and work on their projects by themselves. People are always working together. We heavily value,

strong communication skills.

And 1 thing that we did was we worked with,

this site called Key Values, which was started by another MIT grad, Lynn Tai.

And she really helped us

work through the process of communicating

and,

figuring out what exactly is important to us, And the site's really cool. It allows you to basically kind of browse for different companies by values.

And

we've we've found a number of women who have reached out to us just for because of our profile on that site. I think that, you know, 1, it's really important to have a culture that is great, and then it's also important to

communicate that culture. And so now digging further into the technical aspects of what you're doing at Nylas, I don't know if you can provide

an overview of the way that your platform is architected

and some of the ways that Python is used within that architecture?

So there are a couple major components of our system.

At a high level,

our server platform is essentially

an email client implementation

that will connect to

any email provider out there. It downloads and caches

folks' email data

and makes that available via our front end API.

So what that basically means is that we have a bunch of API servers. They're stateless. They're running application servers. All the application softwares are in Python,

and

developers

can

set up applications

with in which their users

will kind of get bounced out to our servers and go through an OAuth flow and connect their mailboxes to

our system. And when we get a new mailbox connected to the system, we

have a separate pool of machines called the sync fleet, which

in the background starts basically

kind of downloading a cache of all of the email data that is in that mailbox, putting it in our data store. Our data store is basically a fleet of horizontally sharded,

MySQL

machines.

They're kind of standard setup with,

primary replica pairs.

Each mailbox is tied to a single,

a single cluster, and the sync machines download all the data.

They go through this process. It's basically kind of what we call initial sync, where they have to kind of download the backlog first.

And then we maintain

basically persistent connections to the mailbox provider to keep that data store continually up to date

so that the data available via our API is always the latest data that's available

via

the email provider itself.

And there are a lot of different

elements of an email message that you can pull out for being able to query across. So I don't know what are some of the most used and most useful portions of the email message that people are generally

accessing via the API.

So when we designed the API

in,

kind of the beginning, we

we wanted to really simplify

the process of actually accessing

the email data. And to do that, we basically had to decide what was important for folks to be able to easily access.

So

if you are accessing email via kind of the traditional protocols,

there's a lot of kind of,

encodings and formatings that you have to deal with in order to kind of just drill down to an email body or to get an attachment.

And our basic thesis was there's a bunch of headers that are important,

the email body is important,

a list of attachments is important,

and kind of everything else is secondary.

So

we make it really easy to kind of access and filter emails based on their recipients

to, from, you know, cc, bcc, the subject. I think there's a few other headers that we make it possible to filter on.

We

make the email bodies

available

very easily by our by our API, and we also allow you to to query for attachments.

And

if whatever you are building needs something else some like custom headers stuff like that we make the raw emails available via the API as well but we find that the majority of our customers

find the basic representation

sufficient.

And I think that's actually 1 way in which we were pretty successful in the initial design of the API is getting it pretty right What were the most important things that people need

for most most things that they wanna build?

You mentioned that the primary focus of Nylas is as a means of synchronizing users' entire mailbox and then exposing the data contained therein via an API.

I'm wondering what are some of the typical use case is that that enables and some of the ways that people have generally been using that Nylas API?

So the biggest

kind of the the most typical

way that people use our API is for building various sorts of

vertical specific CRMs.

So if you've ever heard the phrase there's an app for that, what we found is that

there's also a CRM for that.

There are all sorts of interesting and,

kind of unexpected

CRMs that we found,

and they're all kind of

need these basic features

of of email and calendaring,

and address

books.

And

the way that they do that is through the Niles platform. So for example, there's people who have built real estate CRMs on us. There's people who have built hiring applications. There's people who have built support tools.

There's people who have built

automotive CRMs,

applications to, like, manage your, like, salon business. It turns out that communication is kind of like a core

human need, and

all of these tools that are specific for managing some sort of business need these features. And you know how, like, back in the day, web frameworks kind of enabled

people to build web applications

for doing just about anything.

Like, there's web applications for managing climbing gyms these days.

And

these frameworks made it so easy to develop web apps that people could do that. 1 of the things that we wanna see happen as a result of Nylas is

all of these applications basically grow these kind of embedded communications and scheduling tools because

it means that people have to switch context less. They're more effective at their jobs,

they have to do less kind of drudgery and manual manual kind of like data entry.

And they couldn't do that before because it was just really hard to connect to email mailboxes.

And for

somebody who is using Nylas to create the CRMs and various communications tools,

is the user facing portion generally something of on the order of a

contact form where somebody will land on the page, fill out the form to request some information or sign up for some sort of mailing list, etcetera.

And then the Nihilus API will then take that, convert it into an email, and then put it into somebody's mailbox?

Or is it more that the

user who's coming on to that site will link their mailbox

so that aspects of their email can be accessed by the person who is using the CRM?

It's more the latter. Basically, these applications will, you know, have in their

settings or set up

a step where folks connect their user mailboxes

to that application.

And then

that connection

seamlessly powers

some part of the application where for example you might have a page in your hiring app where you can see all of the previous communication that people at your company have made with a candidate,

and that's powered by Nylas.

There might be an inline feature for sending out email campaigns

using templates,

or doing some kind of, like,

sales automation,

and those features would be powered by Nylas.

So it's

mostly that there's kind of 2 steps. 1, connect your mailbox.

2, basically use all of these kind of features that people need.

And so

I've been actually on the market for CRMs myself, and 1 of the ways that I've seen for being able to track those communications

is to add a cc or bcc for a particular magic email address that will copy that

communication chain into the CRM for being able to track the various steps of of moving somebody through, for instance, a sales funnel.

And so with Nihilus is the idea that you don't need to use that specific email account and it will just intuit based on the

person's status as a contact in the database that any emails that happen to have their address in either the to or the from field will automatically

be allocated to that particular communication channel?

Exactly. So we just make it more seamless. So when you're developing an application, you don't have to kind of

create this system that requires an email account on a mail server, have to, like, instruct everyone to, like, set up their mail clients to bcc properly.

You don't have to deal with people forgetting to bcc.

We just pull the data straight from the mailbox.

And for doing bulk email campaigns,

a lot of times, you'll use some form of SMTP provider whether it's SendGrid

as just a sort of pure,

data channel or something like Mailchimp for being able to craft the emails and then manage the sending?

Does Nylas

serve that sort of use case as well of being that SMTP channel for being able to fan out the delivery so that you're not,

for instance,

going against the terms of service of Gmail

and their sort of email limits that they might have?

Yeah. So you should think of Nylas as being kind of, like,

a step farther for forward in an outreach pipeline than,

kind of doing this bulk sending.

So we don't actually provide the functionality that these kind of transactional email providers like SendGrid, Mailgun,

those folks provide.

We

if you're using those kinds of services, you you would typically use Nylas as kind of like step 2. So, you know, do a bunch of, like, bulk outreach,

then whoever is kind of engaging with those, you might start to use Nylas as part of, like, follow-up.

We because we're using the kind of mailboxes themselves, don't support sending out mass email campaigns.

But

for kind of folks that are further along in the pipeline,

we provide a lot of features that basically you can't get out of these kind of

transactional email providers.

1, our deliverability is much higher because we're sending out emails through the actual email account.

2, engagement,

is also higher because it's, you know, sending emails just like as yourself.

And it's just generally kind of used for a different

type of interaction

where you're typically reaching out to fewer people.

And because it's sent through the actual email accounts,

we actually can't send

thousands of emails because all of these email providers have

sending limits for each day,

and that's to kind of reduce spam and abuse,

and we respect those limits.

And what are some of the most interesting or innovative uses of Nihilus that you have seen built into some of these applications?

Yeah. Some of the more cool and forward thinking things that people are doing is

not only kind of accessing the email data itself, but also kind of

getting more insight from, like, the connections between the data and stuff like that. So for example, some companies are building things where,

you're trying to

find, the right person at the company to get you an introduction to someone at some other company.

We have all of that kind of connection data in our database.

And you can use it to essentially kind of, like, find out who is talking to who and

basically get actually more information and insight out of the connection data itself.

On a little bit more weirder note,

in the early days of Nylas,

we had 1 person who actually was at a research lab who used our API

to print out

all of the emails

that were sent to his research lab mailing list on

receipt paper,

and apparently, the roll was, like, a 1000 feet long or something like that. It was pretty crazy.

So Nios APIs

suitable for everything from serious business to crazy hacks.

And given the fact that you're dealing with people's personal or work email accounts in their inboxes, and there's potentially a lot of private or sensitive data that's contained in that. I imagine that you have to have a lot of security checks and security protocols in place on the infrastructure that you're using to manage that data. So I don't know if you can talk to some of the controls that you have to ensure that there aren't any data breaches or any,

access leaks of the data for people who don't shouldn't be able to,

view any particular aspects of those communications.

Obviously security is a really really important part of any email platform, and

we take it super, super seriously.

Some things that we are doing to ensure that users' data stays private

are we're we're working

on, kind of complying with all of the various different,

data privacy laws. So,

there's GDPR, which is the new European data privacy protection law, which goes into effect in May.

We are classified as a data processor according to that law, which means we have kind of slightly less stringent requirements than people who are data controllers.

But we are well on track to kind

of providing the abilities to export people's private data and also to ensure the right to be forgotten. So if anyone wants all of their data to be cleared out of our systems, they can just send a request in, and,

we'll make sure that that is deleted within the kind of

allotted time period.

Beyond that, we're also

going through the kind of enterprise compliance called SOC 2,

which,

we don't have a timeline for specifically completing that, but we're kind of in the middle of the process, and it should happen sometime in the next,

you know, some number of months.

We also,

have, you know, folks engineers on our team who work on security

and,

ensure things like, you know, making sure all of our external points of presence are patched and up to date.

Making sure that,

all

onboarded employees go through security training, that folks are using,

encrypted hard drives, that,

we

use the principle of least privilege and folks folks don't have access to the production databases,

if they don't need to that data is encrypted at rest

So we kind of encrypt all of the like mail message data that is in our databases.

We need to keep some

kind of metadata and headers unencrypted,

because it needs to be kind of queryable.

But generally, it's kind of like an ongoing process that we're continually trying to improve

and already kind of

following the best industry best practices

and,

looking to kind of

do as good a job as is possible there in terms of keeping people's data private.

And what are some of the biggest challenges that you are facing either currently

or in the past or anticipate in the future whether from a technical level or from the business perspective?

On a technical level, email inherently

these days involves

a lot of data just in terms of sheer volume.

So our biggest scaling bottleneck from the beginning has always been the size of that data. That's why we had to shard our databases within the 1st year. And looking forward with regards to our application architecture, that's kind of 1 of the biggest constraints.

So as we're kind of looking forward to adding the next, you know,

1, 000, 000 mailboxes,

we we know that we have to architect our system so that data will scale and that

so all of our kind of services will keep operating

in the face of all of that data.

We also

kind of see the next phase of

kind of product development

beyond just kind of providing the raw access to data is actually kind of providing tools that help people extract this, like, extra insight and information out of the data that belongs to them. So that's kind of like creating data processing pipelines,

kind of doing some

basic kind of machine learning

sentiment

analysis, type classification,

extracting contact information from signatures.

So there's all sorts of kind of things that are challenging about

kind of building those sorts of data pipelines at scale and

kind of providing a reliable service.

So kind of 1 thing that's tricky and interesting about running a platform, which makes it super, super fun to work on as an engineer is just kind of the need to be able to, like, look at

what any particular user's experience is. And that user is a developer. They have an application that's running against us. They make some set of API calls and,

you know, we need to have, like, the instrumentation and introspection

capabilities to actually, like, verify that our platform is working as intended

for any given application which might be doing different things.

Yeah. I mean on the business side, we're

looking at kind of

selling to larger companies going forward and,

you know, that brings its own kind

of additional

kind of

compliance and also kind of like

sales challenges.

So

we

we're kind of working on scaling our sales

team. And on a more personal level,

you originally started the company,

I'm assuming, as a sole contributor. And now that you are growing and adding more people, your role as the CTO, I imagine,

is causing you to have to spend less time,

digging into the code and working on the technical details and to dealing more with the people management aspect. So I'm wondering if you can just talk a bit about how you have found that transition.

You're totally correct that in the beginning of the company, I was an individual contributor.

I

contributed large parts to our IMAP sync engine and kind of the other parts of our infrastructure and API. Throughout the last

4 and a half years, I've

worn a lot of different hats as is the nature of any start up. And, you know, there was a point when the entire engineering team also reported to me.

So, kind of

was a full time manager at 1 point, and

it's definitely been kind of, I would say, up and down. I highly recommend to anyone who's thinking about starting a company to get some management experience beforehand if you can,

Because it's kind of a bit of a stressful experience to be flying by the seat of your pants and, you know, trying to do the best for the company and also trying to, like, learn all of these, like, people management skills at the same time. While feeling like you're not competent anymore because you're doing something completely different

from what you've

been doing for a number of years and feel like you're actually good at. At this point, personally, I feel like I'm, like, over the hump and it's, like, starting to get easier. And I have 5 people who report to me. Some of those are individual contributors. We also have a VP of engineering who's been helping us scale the management for the engineering team,

and that's been super, super helpful. I'm also spending more of my time these days on kind of

external facing things, like working with our investors,

doing a lot of kind of recruiting to grow the team,

and just kind of, like, building relationships with folks outside the company since that's instrumental for our success going forward.

And there's definitely challenges to that. I am definitely an introvert by nature, and I've had to kind of figure out how to manage my time so that I can make sure I'm able to recharge my batteries. But

I'm also really excited at,

like, if you think about it, a system where the components are made up of people is also

a system. So there's, like, elements of,

like, the type of thinking that you do as an individual contributor solving problems that you can bring to kind of building the organization itself.

So I'm really excited about

kind of building the machine that builds the machine,

if that makes sense. But it's been a bit of a journey to get there for sure. There were times when I was like, just wanted to go back and code.

Yeah. It's definitely a challenging transition to make when you're so used

to going so deep in the software stack and trying to build up that context and maintain the overall architecture and how everything's playing together and then bring it be so deterministic

and then having to move to trying to translate that understanding to people who are very much non deterministic and have so many different variables that you have to account for and how the overall team is functioning and making sure that they have what they need to be able to learn and grow successfully. So it's a challenging transition to make and I respect anybody who's able to make that transition and be successful in that role. So congratulations on that. And

given that you are so close to the subject of email as a technology

and how people are using it, I wonder if you have any,

predictions

as to how the future of email will play out or any trends that you see developing that would be interesting to call out. There's a couple different things,

here.

So 1 is kind of like an infrastructure side of things.

So right now,

email providers and email platforms

have

were just really not designed for the types of things that people are trying to build for today.

So I see kind of in the future in kind of, like, the 5 to 10 year time span of

these types of, like, more modern features kind of be being built

directly into email providers

so that you don't need to have these, like, intermediate steps of, oh, we need to, like, take all this data and translate it into a totally different form so that we can use it for something useful. 2nd is kind of, like, built in abilities to

connect parts of your mailbox to other applications.

It's essentially, like, all or nothing right now. You can either, like, give some app, like, full access to your mailbox or

not at all, which I was just, like, not a great place to be for security. And it's because email when email was

designed, no 1 was no 1 thought that you're gonna wanna connect parts of your mailbox to, like, 20 different applications.

Email was for sending communication person to person, but email has changed a lot in the way that people are using it.

And

when email was first designed, you know, your mailbox might have had a limit of, like, you know, 10 megabytes or something like that or or less back way back in the day. And now there's just, like, so much

wealth of information in there that I think that

kind of the data is is gonna be key going forward as to, like,

what email turns into. Kind of on the, like, user experience side, I like, we don't really know what that will look like. What we're excited to do as a platform is to, like,

enable people to, like,

experiment and try many different things,

and then

build the tools

that

make it so that many people can, like, build

build those things

easier and faster because

everyone kind of needs the same things at the end of the day. I think that kind of, like, because there's so much interesting data here and it's all very unstructured,

kind of like machine learning and, like, AI technologies will become important at some point because you essentially need to, like, you know, pull the signal out of the noise. And, yeah, we don't know exactly how that will look and kind of excited about working with folks who want to figure it out. So for anybody who wants to get in touch with you and follow the work that you're up to, I'll have you add your preferred contact information to the show notes. And with that, I'll move us into the pics. And this week, I'm going to choose Trello,

which is a tool that you can use for being able to

easily track either to dos or process workflows or you can use it as a project management tool. It's just a very flexible platform,

and I've been able to get a lot of value out of that. I largely use it for managing my podcast interviews lately, so, it's been valuable for that. And, so anybody's looking for any sort of task tracking or,

being able to have sort of just put ideas, it's a great place for that. So,

with that, I'll pass it to you, Christine. Do you have any picks this week? Yeah.

Sort of,

a little bit random or kind of on a different note. There is this really cool website

that just launched today. It's called founders for change.

And the basic gist of it is it's

kind of a compilation of

different founders at many different companies who are committed to improving diversity and inclusion in the tech industry.

So

if you have a company or think of starting a company or

looking to join a company that cares about diversity and inclusion,

you should check out the website. It's at founders for change.org

just launched. Great. Well, I want to thank you for taking the time to talk to me today and discuss the work you're doing at Nylas. It's definitely an interesting platform and 1 that appears to have a lot of useful potential. So thank you for that, and I hope you enjoy the rest of your day. For sure. It's great to meet you, Tobias,

and enjoy the rest of your day as well. Thank you.

The Python Podcast.init

Summary

Preface

Interview

Keep In Touch

Picks

Links

The Python Podcast.__init__

Summary

Preface

Interview

Keep In Touch

Picks

Links

The Python Podcast.init