Tess Rinearson talks building an app for a decentralized music festival at Interstellar and the challenge of managing cryptography researchers

Roshni Rawal
she256
Published in
9 min readApr 23, 2019

Tess Rinearson is the VP of Engineering at Interstellar, a new company formed by Stellar and Chain, building new tools and products with the Stellar network. She came to Interstellar from Chain, where she started as a systems engineer in early 2015. She’s worked on storage and protocol problems for permissioned blockchains, and has written a popular bitcoin explainer using emoji. Before Chain, she was a full stack engineer at Medium.

What got you into the blockchain space?

In 2015, I was working at Medium and I became interested in doing systems and database engineering. Despite there being an obvious connection between blockchain and distributed systems, I wasn’t initially interested in Bitcoin. But I ended up talking to Chain because of the engineers they had on the team. Around the same time, I went on a bus trip and ended up sitting next to a friend who had gotten really into Bitcoin. He spent the four hour ride hammering a lot of ideas into my head. A lot of other young people working in tech were listening and people started asking questions and then we started trying to explain things to people; it was this fun learning and teaching conversation. That’s when I realized that blockchain technology isn’t just something that people use to speculate on currency– it’s a really cool distributed system. The technology was more interesting to me than any of the political, economic, or philosophical purposes. I came at it from a completely software engineering perspective.

What keeps you here?

We still haven’t seen the thing that’s going to make blockchain technology widespread amongst non-enthusiasts. I’m waiting for that to emerge. Right now the only widespread use case seems to be speculation, which isn’t as exciting to me.

What kinds of use cases do you find interesting?

Blockchains should be useful as payment rails and distributed accounting systems, which is pretty interesting.

What does being VP of Engineering at Interstellar entail?

When I became VP of Engineering I wrote a document with help from the CTO and other people on the team, which outlined the things that I expected to be doing to make sure that the team moves in the right direction and ships things on time. A big part of my job is to keep morale high, make sure that the boat stays afloat, and keep everything operating the way it should. So, the tactics of my job are pretty variable. For the past two months I’ve been working directly with the crypto research protocol team, which is doing research around libraries, zero-knowledge proofs, and other confidentiality and privacy protocols. I’ve also been working on educating people around consensus algorithms, since Stellar has a really unique consensus algorithm. I’ve been learning Rust, working on blog posts, and spending time on multiple different things. It’s super variable and my job comes down to the fact that we have to keep shipping things, keep moving things forward, and keep everyone happy and well supported. It’s less about structured time in certain areas, and more about going where I’m needed–which is different than what I initially imagined.

What was the transition between VP of engineering at Chain to VP of engineering at Interstellar like?

At Chain we only had one product at a time. I was working on Sequence, which was a ledger service. It was different because the company had a single product. At Interstellar we have had a broader portfolio of things that we’re working on. Even though Interstellar is now focusing on one product, a lot of my time working as VPE has been about balancing a number of things that my team was working on. Most recently, I’ve been working closely with the protocol team, which has been interesting because I’m managing cryptographers and I don’t have a cryptography background. This has really been about learning to manage people who have much deeper knowledge in a field than I do, which has been a challenge.

How do you go about approaching that challenge?

I try to ask really good questions and I shift the technical decision-making onto the people who have knowledge in that specific area. A lot of my job right now is about ensuring that communication is really clear. I ask lots of questions and, in doing that, try to be a role model for those on the team who, like me, may not have that depth of knowledge. A big secret I’ve learned is that sometimes when people who are really senior say that they want a mentor or more support, oftentimes they just want someone to listen to them, keep an eye out for their work, advocate for them, and help them understand how their work fits into the mission of the company. You don’t need to be at their level to do that–of course you do need some technical background– but you need to be a good listener and advocate.

OMF- Our Music Festival, was a decentralized music festival that took place in Berkeley’s Greek Theater. What was Interstellar’s role in putting this together?

OMF used a mobile app built on the blockchain to engage with fans and encourage them to interact with the festival experience. The Interstellar team built both the mobile app and the Stellar integration so that the mobile app could scan QR codes. People at the festival received OMF tokens and redeemed them for bracelets or collectibles (like badges). The most distinctive part of this was that at the end of the festival they shot a confetti cannon into the crowd and there were QR codes on each piece of confetti that users could scan for tokens. It was a literal airdrop, although as a back-end engineer it’s a bit scary. In server-side engineering we have this concept of “burstiness”, where you may have no traffic and then you have a spike, which can be hard to react to. This was the most bursty thing you could imagine– to have a cannon shooting QR codes that people could redeem.

Did you end up going to the festival?

I didn’t go to the festival. I was here in our office with a couple of other people watching the logs and graphs, hoping the server and the network handled everything well.

Were there any technical issues or did everything go smoothly?

Everything stayed up. We put in a lot of engineering time and energy into making sure that we were batching transactions properly, so that if people tried to scan many QR codes at once we could issue tokens as a batch rather than queuing everyone up one by one. It was a fun engineering challenge.

What was the community reception to the decentralized aspect of the music festival?

I’m not sure how prominently crypto aspects of the festival were advertised. A real strength of blockchains is that you can completely obfuscate the fact that an app is using the blockchain. A lot of people don’t care how things are built as long as they are safe, secure, and fast.

What kinds of questions arose in your mind after building this blockchain use case that was directly interacting with consumers?

I wonder about a lot about what level of understanding the average will person have of blockchain in ten or fifteen years assuming that the technology becomes widespread. I think about the level of understanding that most people have about how the internet or how mobile apps work, and it’s not clear to me what the equivalent analogous level around blockchain is.

In your talk “An Over-Engineering Disaster with Macaroons” you discuss Chain’s initial adoption of Macaroons for authentication, and later the realization that Macaroons may not be the correct technology. What’s the process of realizing that you’re “over engineering” something?

In retrospect over engineering becomes really obvious. When you look back and you see that you’re doing extra work for something that you don’t need– it’s over engineering. Ensuring that multiple people with different perspectives are making technical decisions is one way to prevent over engineering. Having checks and balances when making technical decisions is good, which goes alongside having clear documentation and specs. Finally, I love the idea of using innovation tokens (a concept introduced to me by a blog post by Dan McKinley). Essentially, for every product you get three innovation tokens, and every time your team makes a decision or a choice that requires innovation you have to spend one. You might spend innovation tokens on using a new database, programming language, or authentication system. You can even spend an innovation token on a new organization structure. Each time you choose to invest in an innovation it may distract you from your core mission, which is why you spend your tokens wisely. Innovation tokens allow you to limit the number of experiments you choose to make while building a product. I use this framework with my team and myself to walk myself back from making ambitious decisions at times. I’ll be like, “that’s a really cool database, let’s try it out” and then I think, “no, there’s not a lot of documentation, let’s go back to PostgreSQL, which everyone on the team has used and serves a lot of companies really well.” This framework is really helpful for me and my team.

Do you actually allocate a certain number of innovation tokens per project?

Not really. More often we look at potential innovations and think about whether it’s worth spending an innovation token on, and how many we’ve spent already, which is less rigorous than actually allocating tokens. But even just thinking like this goes a long way.

What’s the most interesting project you’ve worked on at Interstellar?

It was cool to work on the OMF mobile app, since I got to see a crypto product in the hands of users, which is not something that I’ve seen much of. It scratched a consumer itch that I forgot I had. I used to work at Medium, so I’m acquainted with the process of building a product that lots of people pick up and love, but I’d forgotten about what that felt like.

My work at the research team has been pretty exciting since I’ve learned a lot about distributed systems and cryptography. One of the things about doing research at a company is that the work ends up being split into teaching yourself and coming up with new things, and then turning around and communicating all those things to a group of people. There’s a huge amount of work that goes into communicating and teaching people the ideas you come up with, almost like marketing what you come up with.

You dropped out of college to join Medium. How did you get the opportunity? Why did Medium appeal to you?

I knew one of their engineers, and she was someone who I really admired and who seemed really happy at Medium. Actually, the reason that I went to work at both Chain and Medium was that at each company there was specific senior engineer who had skills that I wanted to learn. I would definitely recommend this to new grads who are trying to figure out a good place to go. When in doubt, just find the people who are the kinds of people that you want to be and mimic them. I don’t know how successful I became at being like these people, but I certainly learned a lot and had a really good time. They have all been wonderful mentors and friends to me. That’s what drew me to Medium in the first place.

Why did you decide to drop out?

I didn’t like college very much. I have a lot of friends who dropped out because something was pulling them away from college, like starting a company. Other friends dropped out because they just hated school. I’m somewhere in the middle. I’ve always had this urge to build things and I was not able to scratch that itch in college. I went to a lot of hackathons and did a lot of side projects, but those were just extracurriculars. It was hugely satisfying to go into the workforce where my job was making things for people to use. My life opened up because I felt like I didn’t have to scratch that building itch on the side. Instead, I was getting paid to do that! It just felt like the right thing to do.

What do you think you missed by dropping out (if anything) looking back now?

When I’m working with the cryptographers I do feel like I’m lacking in mathematical depth. I’m not sure that I would have gotten that if I had stayed in school, but there’s a certain level of fluency in terms of writing proofs and expressing ideas that I find myself under practiced with. I compensate by just trying really hard, and asking a lot of questions.

In this piece on Medium you talk about why technical entitlement creates a toxic learning/working environment. You talk about a “friend choosing not to be one of those people”. How can we all choose not to be one of those people?

There’s an organization called the Recurse Center that has some ground rules for engagement. These are all actionable guidelines around not holding your technical experience over other people. These are small, but really concrete things that you can do. This is a great starting point and it’s easy enough to just keep a few guidelines in your pocket and use them.

Connect with Tess on her Twitter and LinkedIn!

Write to Roshni Rawal at roshnirawal@berkeley.edu. The she256: Fireside Chats are sponsored by Upscribe.

--

--

Roshni Rawal
she256
Editor for

EECS @UCBerkeley, Creator of @SHE_256: Fireside Chats