Podcast: Nylas CTO Christine Spang on Debian and the Transition to CTO

Christine Spang's Open Source Journey from Teen OSS Contributor to CTO of Nylas

A few weeks ago our CTO Christine Spang sat down with Scott Hanselman, host of Hanselminutes and part of the Web Platform Team at Microsoft. They chatted about Debian, how (and why) she got started in the programming world, and what her transition to CTO has looked like. 

Here are a few of our favorite quotes from the show:

Regarding what it’s like to be CTO and not contributing code every day:

As CTO, I keep myself out of the critical path for shipping new features or doing major projects. My work on a project should not be a blocker to shipping it. It's the different between “maker mode” and “manager mode.” When you're in maker mode, you need long stretches of time so you can get in the flow when you're working on building something, whereas manager mode is like, "I'm pulling myself out of the details. I may be monitoring how various different things are going. I'm talking to lots of people and communicating a lot. I might be meeting with external people who are not actually employees of the company." It's hard to switch back and forth between those two modes. If you're trying to do that, it makes the project work go slower. I find that while letting myself dig into the technical work is very enticing, I’ll wind up neglecting other things that are very important. I won't respond to e-mails for a long time and that's bad.

How she helps fight “bus factor” at Nylas:

As the person who's been there from the beginning and has been in charge of the health of the backends, I've been the one who has also made sure that we understood how the code works and that other people could work on it.

On being a female founder and CTO in the tech industry:

There's a certain extent to which just existing, is changing the status quo a bit. Making tech more inclusive is also really important to me. I've definitely been in places where I've beat myself up a little bit because I feel like I'm not doing enough. I just have to remind myself over time that just existing and succeeding in this role is contributing in a way.

Listen to the full podcast here or download it via iTunes, Spotify, or Google Play.

Transcript

[00:01:03] Scott: Hey, friends. This is Scott Hanselman. This is another episode of Hanselminutes. Today, I'm talking with Christine Spang. She's a co-founder and CTO of Nylas, and a very long time Debian contributor. How are you?

[00:01:15] Christine Spang: I'm doing great.

[00:01:17] Scott: I'm looking at your LinkedIn and I am just blown away. You've been doing Debian for- now what? 11 years?

[00:01:24] Christine: Yes. It's a bit of an interesting story. Debian is instrumental in how I got into computing, actually, and how I decided that I wanted to be a software engineer. The story goes a little bit before I actually started using Debian. The reason that I ended up using Debian in the first place was when I was in high school, I got really into computer gaming. I was really interested in trying to find the games that had the fewest rules for stories that you had to follow as possible because -- I guess I wanted to live in another world and explore, but I didn't want to have to do exactly what the game creators told me to.

That eventually led me to playing these online games or multiplayer games. They were text-based, called the MUDs. How this ended up with me getting into Debian was, after playing one of these MUDs for a while, it was actually a Lord of the Rings theme to MUD, I started actually helping out run it because they had basically administrators that helps run plots and this MUD was a very role-playing focus. Everyone had to spend a lot of time creating a character and writing their description and figuring out what their backstory was and their personality.

Then the admins would have to go through these and approve the characters before they went to the game, to make sure that it was rich in theme world. I eventually became one of these role-playing administrators. Those people would build the areas of the world. They would run storylines and parts of the world and just make the world come alive. If you were just a role-playing administrator, you were limited to using the tools that existed in the game world to create new things, whereas I viewed that they were basically like two people on the administration team at this MUD that knew how to code.

I pretty much viewed them as having superpowers because they could actually change how the game world worked and create entirely new things that no one else had imagined before. I really wanted to learn to program in order to be able to contribute to this game world in a way that I couldn't. For one, the game's code base only read a Linux. My uncle used Linux. He ran Debian. He got my twin brother into running Debian. I had my twin brother help me install Debian on this- you know those like tower computers that people that had back in the day that--

[00:04:19] Scott: Yes. Was that the white or the beige one, the big giant one?

[00:04:23] Christine: Mine was actually kind of dark gray. I think of it as from CompUSA or one of those big box stores that no longer exist anymore. Back in the day, it was a feat to manage to install Debian alongside Windows and not accidentally break your Windows installation because the partition editor was like no guardrails in some ways.

[00:04:50] Scott: Yes, exactly.

[00:04:52] Christine: We were really excited to have managed to install Debian on this machine without breaking Windows because I didn't know if I might still need it. I might need to do my homework or something. I was in high school at the time. It was a little too risky to just wholesale replace it.

[00:05:12] Scott: As you haven't needed Windows for 11 years, so you probably can delete that partition.

[00:05:16] Christine: Yes. In fact, on my latest laptop, I-- Every time I buy a new laptop these days, I just completely wipe it away. With this recent one, a couple days after doing that, I consider whether maybe I should have kept it this time because-- I think it might be good to tackle a bit more about this later, but as a CTO at a company, I spend a lot more time talking to and working with people who are not programmers. I worry that maybe there's something that I might need Windows for to deal with some obscure Microsoft tools or something. I just borrow someone's laptop when that happens.

[00:05:54] Scott: [laughs] That's a good system. The thing you didn't tell me though is that this is when you're what, 14, 15 this is all happening?

[00:06:01] Christine: Yes. I was 15, 16 at this time. I installed Linux. I started trying to teach myself C because the MUD server was written in C. C is really not the best language to learn as your first language. I would not recommend it because it's really a pretty low-level language. I remember I bought the classic C book which is the Kernighan and Ritchie book. I remember reading it. There's this chapter on pointers. I'm pretty sure I read that chapter three times because I just couldn't wrap my head around the idea of what a pointer was. Eventually, after spending enough time with it, it clicked. I have very vivid memories of it being very difficult.

[00:07:01] Scott: I have the same experience. It says pointers, pointers, pointers. Then at some point, it clicks. It's like, "Okay. That makes total sense."

[00:07:07] Christine: It's mind-blowing, as not having background with a lot when it comes to computing, just having that be your intro and being like, "What's a memory address? Whoa, this is pretty incredible."

[00:07:22] Scott: I have a question, a sidebar question about this because this is interesting. You and I have very similar histories, in that we were thinking about memory and pointers and instruction, that level. This is what Maria on my team calls "learning from the middle up." She says- she's a little bit younger than I am- that she learns from the glass of the monitor back. Meaning, she wants to go into the browser and hit at 12. At some point, she just accepts that the obstruction is the obstruction. For her, maybe Javascript is the middle, or maybe Go is the middle, or Python is the middle. Do you think that we come built in as a top-down or bottom-up learner?

[00:08:05] Christine: That's a good question. To be honest, I'm not--

[00:08:08] Scott: Do you drive a stick shift? Do you know what I mean? That's what I'm asking.

[00:08:11] Christine: I don't drive a stick shift, but I do know how to drive a stick shift.

[00:08:14] Scott: There you go. See, that's the thing, changing oil.

[00:08:17] Christine: Yes. I never really thought of that before. I'm not really convinced that either one of them is the one true way. I'm one of these people who knows how to low level program but have the utmost respect for high-level programming because it's not less complicated, it's just complicated in different ways.

[00:08:39] Scott: Yes. Someone told me once that success is a pretty good metric. If you don't know Assembler but you lodged Twitter, well a success is a pretty good metric.

[00:08:50] Christine: I feel like in computing lore, there's this- and just the culture and what we value. There's this mythos in low-level, close to the machine programming. I'm a little skeptical of it as a measure of how great a programmer you are.

[00:09:13] Scott: Well, I don't think being a-- For me, it's not about being a great programmer. Everyone is different. It's more about what is the best way to effectively get computing information into a team, into a person. The problem is, everyone's a different kind of learner.

[00:09:29] Christine: Yes.

[00:09:33] Scott: Audible learners, visual learners, people who read kinesthetic learners. Not everyone wants to say, "Hey, let's talk about double pointers."

[00:09:42] Christine: I guess I would agree that I like to know the details and obstruct from their road than the other way around though. It's definitely the case, that sometimes when you're learning a new thing that's a new programming language or a new framework, at some point, you're going to be in a situation where you almost have to deal with the fact that you don't understand what's going on and roll with it for a little while.

[00:10:11] Scott: Well, and then at some point, you have to decide, "Okay, this car is not starting. Am I going to open the hood, or am I going to hire someone to open the hood?" Now you went to MIT after this, and then went on and worked on kernel patching at Ksplice, which is basically doing Linux security fixes without rebooting. What is that? Changing the engine on the car while it's driving on the freeway at speed.

[00:10:34] Christine: Yes, pretty much.

[00:10:35] Scott: [laughs] That's definitely opening the hood and then flipping the car over.

[00:10:40] Christine: Yes. At MIT, my favorite class was actually the operating systems class because it just made me feel like a wizard to actually access the low-level hardware. If you mess up, your entire computer can crash. I just thought it was the funniest thing to inspect network packets at the packet level and make them go and think about the fact that data is moving through the hardware of this machine. It's really exciting.

[00:11:18] Scott:  Have you ever seen Julia Evans’s “So you want to be a wizard programmer?”, Zine?

[00:12:27] Christine: I totally have. In fact, I know Julia. She's amazing.

[00:12:32] Scott: She is amazing. That way of presenting information, this is like a fun, cool you have power. You are empowered, you are in control. It's such a fun way to get people excited about computers.

[00:12:45] Christine: Yes. Computing, in general, is just like an incredible feat of human ingenuity going from the subtraction that's high voltage and low voltage, and somehow ending up with these crazy information machines that now allow us to automate things and aggregate large amounts of information.

[00:13:13] Scott: Not to mention that it's all so broken and it still works.

[00:13:18] Christine: Yes, I agree with that. I haven't been rebooting for a while. It's amazing that any of this stuff works.

[00:13:25] Scott: Yes. I'm on an Intel machine running Windows and I haven't rebooted in 24 days. Maybe you're Debian, on an AMD, and you haven't rebooted in, I don't know, 20 years, however long.

[00:13:36] Christine: [laughs] I did actually log into my server the other day and realized that I was two major releases of Debian behind. If you know Debian, they don't release very often. It's a stable release every two years. I only had updated that server in about five years.

[00:14:01] Scott: Fast forward a little bit and you've gone from muds to hot patching the kernel. Then you decide to start a company. Right now, you're the CTO at Nylas. That's N-Y-L-A-S.com. CTO, that's the C level? What do they call it, the C suite?

[00:14:23] Christine: Yes.

[00:14:25] Scott: That's kind of a big deal. You're on the stock filings or whatever. That doesn't sound like the person who's patching the kernel. That sounds like a business person.

[00:14:36] Christine: CTO is interesting. I think it would be useful to give a little backstory as to how I ended up in this position.

[00:14:44] Scott: Please.

[00:14:45] Christine: Even before I started the company-- At this company, Ksplice, doing kernel patching, and the founders of that company or some people that I met at MIT through the MIT Computer Club. After about a year of being at that company, the founders sold the company to Oracle, and stayed at Oracle for a little bit. It's through that experience that I pretty much came to the conclusion. This is my first time ever working for a really large company. I didn't like it. I had been thinking about what was going to be my next step during my time at Oracle and ended up starting this company with a friend of mine from college. In the beginning, the split between me and my co-founder Michael was pretty much that the product idea was completely him. It was like based on something that he had worked on as his undergraduate thesis.

He had basically been trying to build some stuff with e-mail and was like, "Wow, this is really difficult to actually even access the data. Maybe this is why people haven't been building new, innovative things that work with this core technology that everyone uses but no one really loves." He was always the initial product visionary in terms of what problem we were trying to solve. I really joined as the implementation chops, where I was doing backend engineering.

At Ksplice, we had this huge VM farm because part of the way the technology worked was that every time you were converting a source code patch to a binary patch, you actually had to compile the patch against every single old version of the kernel that you were trying to update, which was basically every single kernel that had been released by every single Linux distro out there. That meant there was basically hundreds of builds that we had to do for every single patch we're updating. We had this pretty complex VM infrastructure that automated parallel building of all of these kernels as fast as we could.

It was a really different product space, for me to switch to working on e-mail, but I came from a backend engineering background so it made a lot of sense for me to start building out the sync engine that we use to sync data with e-mail servers. Michael pretty much figured out what was the design of the API and worked with some other folks that were early in the team to do that. I was focused on the lower level infrastructure and data storage and figured out how we were going to make it much easier for clients to be able to sync and brought all of our first infrastructure up and stuff like that.

It was a definitely super, super hands-on in the beginning. We didn't really have titles at the early days of the company. When you're six people in a tiny office and you're all just working on building the product, it's not really useful. I think of titles as being mostly useful for people outside of a company, actually. Once you get a company to a big enough size, it becomes useful internally because people don't know everyone super well. They need to know what you do.

I think it was about two years into the company, people on the team just actually just started referring to me as the CTO, which wasn't really something that I had pushed. I just rolled with it because I was acting as the lead architect for the backend. The term CTO can mean a lot of different things, I found. What that person does differs a lot from company to company.

It's not that weird at a very small early stage startup for the CTO to actually be very, very highly technical and doing some architectural work on the actual product. I think it was an appropriate title for me at that point in the company. Since then, I feel I've grown more into the mantle of what a CTO does at a larger company. That has been actually really good for me in terms of growth.

I still consider myself to be highly technical. People on the team actually still send me code reviews and stuff like that. The company right now is about 25 people. About half of that is engineering. My role has definitely changed a lot. I'm not writing code all day every day. I keep myself out of the critical path for shipping new features or doing major projects. What I mean by critical path is that my work on a project should not be a blocker to shipping it.

[00:19:58] Scott: Sometimes we talk about the bus factor of a person. Have you heard that?

[00:20:02] Christine: Yes.

[00:20:03] Scott: Right. What if Christine gets hit by a bus, can we still ship?

[00:20:06] Christine: Yes. Even beyond the bus factor. Bus factor can be like, "Does more than one person know how this system even works?" There were definitely points in the history of the company where it would have been really bad if something had happened to me because there were things nobody else understood. There were other people in the company that were experts on certain things and no one else really understood.

As the person who's been there from the beginning and has been in charge of the health of the backends-- I've been the one who has also- when people have come and gone, made sure that we understood how the code that they wrote worked and that other people could work on it. More so today than being not critical the shipping and project, I want to not be a blocker.

As the company has grown a lot, I have a lot more meetings in my calendar than I used to. There are these two different modes of operating. Have you ever heard of Paul Graham? He wrote an essay about this. It's like maker mode and manager mode, more like when you're in maker mode, you need long stretches of time so you can get in the flow when you're working on building something. Whereas manager mode is like, "I'm pulling myself out of the details. I may be monitoring how various different things are going. I'm talking to lots of people and communicating a lot. I might be meeting with external people who are not actually employees of the company."

It's hard to switch back and forth between those two modes. If you're trying to do that, it makes the project work go slower. I find it's very enticing that if I led myself do too much technical work these days, I will neglect other things that are very important. I won't respond to e-mails for a long time and that's bad.

[00:22:17] Scott: Are you concerned that you would lose your technical ability after so many years of being so technical?

[00:22:23] Christine: I definitely think about that sometimes. Most of my time on a week to week basis is not writing code but I still understand how all of our systems work. I help guide architecture. I'm talking one on one with the senior engineers on our team on a regular basis, helping figure out what direction we want to go in. I also am still a part of our rotation for dealing with customer bugs. That allows me to get my fix of writing a little bit of code sometimes, and also just stay in touch with what are the things that go wrong, what our actual customers are experiencing.

I'm able to write patches that fix things for that. I do find that when I am the person who's in that rotation, one, it takes me longer to ramp up than I used to. Because there are some meetings that I can't really put off or not go to during the week, I'm not as effective as a full-time engineer on that rotation. It's something that I'm keeping an eye on at this point. For me, I've always thought about my role at the company as, "What does the company need most from me most right now? What's the highest leverage thing for me to be doing?"

As a founder at a company, you almost occupy a little bit of a spiritual, symbolic role where-- Actually, it was really important to me, when we started the company, to focus a lot on the culture because doing a start-up is one of the few chances that you get to actually start from scratch when building how an organization works. As a person who's been here from the beginning, I've used my responsibility to be the steward of that culture.

As the company gets bigger, there's more work to be done with that. For example, we've been doing this thing where we have- basically, every six months, we'll have a whole company off-site and talk about high-level strategy, our company's values, and the mission of what we're doing in trying to accomplish and going after. For the last one, I'd spent a fair amount of time preparing beforehand.

I used that as an opportunity to get feedback from the team about what we like and don't like. We have an Open Source handbook that we've published on GitHub with our values and company policies. It's a way to communicate both internally to people who are joining the team and also to external people who might be wanting to know more about us, or even other people who just want to get a great parental leave policy and just copy it.

Revising that and keeping it up to date is something that's really important to me because as you add a lot of more people to a team, they only know what you tell them about how the company operates and what they see. This communication of what's important to us is vital to keeping the culture going as the company grows.

[00:25:55] Scott: You've mentioned lead developer, then chief architect or lead architect, then CTO. As you uplevel, I'm hearing you say as you uplevel those things, you're going from being the smartest person in the room or being the technical one or being the kernel patcher to being the big picture person to being the bridge between the business and the technology to being a culture setter for the technology division of your company.

[00:26:26] Christine: There's a few more things to it too. For example, there was a point during the history of the company, that I actually managed every person on the engineering team. I had done a tiny little bit of management before at Oracle, but I only had two people who reported to me there. It wasn't really a full management load. At least I got to practice a little bit.

I would say that listening and empathy is one of my strong points. I really enjoyed having an opportunity to exercise that ability. I found management as also a different mode of operating. I would say that you have to think about it a little bit differently to find it satisfying. I found over time that it has grown to be a thing that is exciting to me. The thing that I find exciting about building technology is filling out all the details of all of the components and making something that works that allows you to do something that you couldn't do before.

You can almost think about building an organization in the same way where you have slightly different components, the components or people. More and more over time, I feel like I've developed this ability to get excited about accomplishing things through other people, rather than doing everything myself. It's also exciting to see how much more you can get done by harnessing other people and creating an organizational machine that is empowering and that makes it easy for people to collaborate together and do great things.

It's definitely been a bit of a journey. I'm excited about the organizational side of things too. I think that it's not the natural path for everyone, but I feel like it's working for me. There's not really anyone else at the company who could occupy this role in quite the same way. I think it's really important for me to stick to it.

[00:28:37] Scott: How often do you have to posture a little bit and remind yourself, maybe if you're talking to an investor or a business person, how often are they're going to say, "She's the CTO?" How often does that happen?

[00:28:51] Christine: I've never had anyone say that to my face or--

[00:28:54] Scott: Yes, of course. I assume that it would never- and hopefully, it would not happen to your face.

[00:28:57] Christine: Look actively, disconcerted. I do think about-- I'm a little bit delighted about the fact that, probably, when I walk into the room sometimes, it's a little bit shocking to people. They're like, "What?"

[00:29:12] Scott: You revel in that a little bit?

[00:29:14] Christine: Yes. I was a female founder and also a female CTO at a company. There's a certain extent as to which is just existing, is changing the status quo a bit. Making tech more inclusive is also really important to me. I've definitely been in places where I've beat myself up a little bit because I feel like I'm not doing enough. I just have to remind myself over time that just existing and succeeding in this role is contributing in a way.

[00:29:51] Scott: I think that's a good way to put it. You can talk about what you're doing and you can spend all of your time doing that, or you can do the thing you're doing and simply by being visible and by kicking butt, people will see that. People can go up to nylas.com, N-Y-L-A-S. I was able to go, just scroll down a little bit where it says "developers first" because I'm a developer. I was able to try a live example of how the API works in my terminal, run Coral, and look at messages just right there with Coral or HTPIE or Wget. It's pretty slick.

[00:30:27] Christine: Yes, definitely check it out.

[00:30:30] Scott: Thank you so much for chatting with me today.

[00:30:31] Christine: For sure. It's been really great. I really enjoyed getting to know you a bit, Scott, and having this conversation.

[00:30:37] Scott: Cool. We appreciate you. [background music] This has been another episode of Hanselminutes. We'll see you again next week.

About Author

Tasia Potasinski

Tasia is the Head of Marketing at Nylas. In her free-time, she enjoys drinking soy lattes and reading good books.

Subscribe to Engineering Blog Updates

Start Developing Today

Connect up to 10 accounts (email, calendar, and contacts) for free today.

Start Free Trial