An Inside Look with Codeship: Brendan Schwartz, CTO of Wistia

Brendan Schwartz is the CTO of Wistia

, a video hosting service for businesses. Here at Codeship, we’re big fans of what Wistia’s been doing. We recently got the chance to sit down with Brendan Schwartz and chat about how Wistia made its biggest decisions, the value of face-to-face team work, and the challenge of too much data.

An Inside Look with Codeship is a regular series providing an insider’s perspective on founding and building a tech company. Each session, we chat with some of the most exciting voices in tech and ask them where they’ve been, where they’re going, and what we could all be doing together. You can read all Inside Look interviews here.

I’m the CTO at Wistia, and I spend most of my time running the product and engineering side of the company.

It’s a pretty common story: Nine years ago, we started with something completely different than what we have today. We originally set out to build a portfolio website for artists.

It was a good idea, and we created good technology and a good product, but we had no idea what marketing was. So we built it and had some people using it (many friends and family), but it didn't take off. And here's the thing: Even if it did take off, artists don't have much money.

It was going to be hard to make a business out of it.

We were nine months in and completely broke, but my co-founder, Chris, and I were having the time of our lives. It’s fun to build something of your own. But we needed to figure out how to sustain ourselves and build a real business.

Around the same time, we were talking with a good friend of ours about our product, and he mentioned that his company was having trouble with private video sharing. We knew our product could help, but we were hesitant to change our focus. “No way, we’re for artists, man.”

As time went by, we talked to more and more people in different fields with this same predicament, and eventually a light bulb went off for us. We realized that the desire to securely share video was a common one, and we could build a product to help a lot of people.

Once that clicked, we still focused on private video for a while. But our users were begging for a way to share video publicly on their websites. We resisted at first (notice the theme here), but we eventually listened and realized people found this really valuable. That’s when we shifted to a video marketing focus, and things really took off.

We always had a strong inclination towards solving a broad set of problems with one simple solution. Once we realize that we can build something simple that will be widely applicable, that’s when we get excited about it.

When we started working with our first customer, they wanted us to be a contractor for them. They were asking for all kinds of things, like drawing on the video frame for presentations and so on. All very reasonable features that’d be useful for a particular use case. But we have always been drawn towards the simplest thing that will help the most people. That’s always been our guideline.

We could have made way more money as a contractor, and they’d get a bespoke private video sharing system, but saying no meant having more control over our product. This decision set an important precedent.

All the things we build are a result of customer feedback, but there's a big difference between building exactly what someone says they want and taking the time to truly understand the root of their problem and building the best solution for the market.

Sometimes, it might seem like we're slow to respond to requests, but we're often taking the time to gather sufficient evidence in order to build simple, sustainable solutions that will benefit a wide audience. We've found it's easier to add features than remove them, so building without a thorough understanding of the issue can be a slippery slope.

That being said, when customers first began asking to share their videos publicly, we wanted to make it possible for them, despite the fact that we weren't adding that functionality to our product. Our teammate, Ben, began emailing those customers video embed codes that he generated by hand. After Ben sent out over a hundred of these hand-crafted embed codes, we realized there was a larger need than we anticipated, so we decided to add it to our product (much to Ben’s relief).

From the start, we’ve had a very in-person culture. When we started, Chris and I were living together in a six-person house in Cambridge and working out of an office in my bedroom. So we basically spent every waking hour together. It’s hard to get more in-person than that.

When we joined up with two other folks a year and a half later, we moved into a real office, and all sat around one big table. We’ve always been addicted to the energy you feel when you’re working together in person -- you effortlessly have all sorts of spontaneous conversations, you can go on a walk and have a rambling creative discussion, you can run around the office and get people excited. Maybe it’s just me, but there’s a certain feeling I get from working together with people in the same space that is just impossible to get when you’re remote.

Of course, there’s a downside to this. Companies with remote cultures can easily hire the best people in the world. They don’t need to have the discussion about relocating people or their families. Also for things like customer support and engineering ops, having coverage in different timezones is an amazing thing. We’re entirely based in Cambridge, Massachusetts. So if a customer in Australia writes in with an urgent problem, they’ll have to wait half a day to get a response. And if a server fails over in the middle of the night, that means someone on the team is getting paged and woken up.

It’s foolish to say that we’ll never be able to support remote work, because it’s such a valuable tool, but there are a few things I know for certain:

I’m addicted to our in-person culture, and it gives us so many creative advantages. We’d be crazy to ever give that up. It’s really difficult to be a remote worker for a company that has a strong in-person culture.

I think we have a lot to learn and a lot of hard work ahead of us if we want to have some remote work fit with our in-person office culture.

I’m a firm believer that the best products are built by people with the most context. If you truly understand the vision, the market, your customers, all aspects of design and engineering, and the business model and finances, you will create an amazing product.

Now, it’s next to impossible to have both a broad and deep understanding of all these areas, but I think it’s the right thing for everyone to aspire to. What we’re trying to do at Wistia is build a company full of people who are innately curious and nurture a culture where it’s valued and respected to have a broad understanding of how the business operates.

When everyone shares that understanding, it’s so much easier to work with other parts of the organization and internalize their priorities and goals. I’ve found this makes everything work much faster, and you end up with much more creative solutions to problems all across the business.

As a result, if you’re on the engineering team at Wistia, you’re talking to customers, handling support tickets, optimizing our marketing funnel, and helping solve financial challenges in addition to building product and infrastructure.

And on the flip side, if you’re not on the engineering team but want to learn about software development, that’s very much encouraged.

I was talking to Emily (who works on our support team) the other day, and she had all these great ideas for changes in our app that would be relatively easy to implement (like copy changes and adding links to relevant documentation pages in certain places).

It would have been easy to have someone on the engineering team make those changes, but I asked her if she was interested in learning how to make them herself. The answer was a resounding yes. She paired up with an engineer, got her development environment set up, submitted a pull request, and deployed her changes. The next time there’s a change she wants made, she’s empowered to make that change! That’s so amazing! “Teaching a person to fish” is baked into our culture.

We look for people who are really curious. It's pretty easy to gauge curiosity based on someone's responses in an interview. When we start talking about different aspects of the business, do they ask thoughtful questions? It's really telling what questions people ask.

Sometimes engineering candidates are only curious about technical things, but we look for a broad curiosity. Some people ask about the business side of things because they're genuinely interested -- that’s great. I’ve also talked with plenty of people who got burned working for a company because the business model was bad and they now recognize how important it is to understand that. It’s not great that they got burned, but it’s amazing they have that newfound motivation and excitement to get involved in more parts of the company. Motivation and curiosity are what matter to me when hiring.

I love simplicity! That’s something that we hold in high regard within the product and in the underlying technology stack. We spend a lot of time doing technical design, and the systems I'm always most proud of are the ones that are so, so simple. The ones that are so impossibly simple that you look at them and think, "Wow, this actually works at this scale?”

I think some of our best achievements are code or systems that were designed six years ago and are still running in the same way as they were originally designed, with very minimal changes. I think that’s an indication of an engineering job well done.

One thing we’re working on right now—and will be working on until the end of time—is measuring and really understanding video playback performance. It’s a very difficult problem because so many factors are out of your control. When you measure things like that, it’s very difficult to figure out what to measure and how, because there are so many variables at play.

Take, for example, your user’s connection speed. It’s not a static thing. It’s constantly changing, and for video in particular, there are different ways to balance quality and deliverability, based on what device they’re using, where they’re located, macro-conditions on the internet, etc.

You have to choose what things you want to optimize for. It’s something that we’re pretty good at, but I also feel like we haven’t solved the problem. I’m not sure we ever will, but it’s a really fun one to work on.

I’m really excited by technology like Amazon’s Elastic Map Reduce and Redshift. Tools to analyze large datasets have existed for quite a long time, but by having them hosted, making them extremely easy to set up and use, and being able to pay only for what you use, Amazon is making it much easier for individuals and organizations to work with big data sets.

I’d say these tools were definitely a missing piece of technology for us until recently. We have been collecting and processing large data sets for many years but doing so in a very specialized fashion (e.g., our system for collecting and analyzing our customers’ video engagement data).

EMR, Redshift, and Pipedream (an internal general-purpose data pipeline we constructed) let us be much more liberal in the data we collect and analyze it on an ad hoc basis. This has been transformational for us.

Before these tools, we were in this state of data paralysis. How should we collect the data? Should we just set up a server and log it out? How will that scale? And, once we collect it, where would we store this data? In flat files? In a relational database? Should we be experimenting with a new type of data store? How will we analyze this data?

So any time we wanted to measure some small thing in our product or infrastructure, we’d find ourselves mired trying to answer all these questions.

It took a lot of work over the past year and a half, but we have the beginnings of a data pipeline for collecting and analyzing large amounts of arbitrary data from across the business. Now there’s a well-thought-out answer when someone says, “Hey, I want to measure this.”

There’s certainly much, much more work to do here and lots of gaps in our current system and tools. I very much look forward to the day I can wake up in the morning, have some random hypothesis about video delivery performance, and be able to validate or disprove it before breakfast.

Lack of diversity in the tech industry is something that’s on everyone’s mind (at least, I hope it is!). One thing I worry about in particular is that diversity is a difficult topic to talk about. I think there are a few reasons for this, mainly:

• We’re self-conscious that we’re doing a bad job or not doing enough when it comes to diversity.

• We’re afraid that we’ll say something insensitive or offensive without meaning it, and we could be accused of being racist, ageist, or sexist if we say the wrong thing.

• It can feel overwhelming because there’s not a clear or easy solution, so we aren’t sure where to begin or if we can help.

These are legitimate reasons for a topic to feel intimidating, but, to me, acknowledging and talking openly about lack of diversity is hugely important. If we don’t talk about it, how can we expect to make progress?

And if you run through the reasons I just listed, they’re not so scary if we think about them more critically.

First, there’s a lack of diversity in our industry as a whole and in nearly every individual company in our industry. I certainly feel self-conscious about a lack of diversity at Wistia, but I recognize I’m likely not alone in feeling this way. There is much more all of us can do, both as an industry and in our individual companies.

Second, we should generally assume people have good intentions. After all, if someone is participating in a conversation about how to increase diversity in technology, they are trying to help.

Third, the fact that lack of diversity in tech is a really hard problem without a clear solution is exactly the reason it’s so important that we discuss it. This is not something we can just “solve."

A degree is useful, but I don’t think it should be a requirement for anything.

I have met plenty of extremely capable and smart people who do not have college degrees. I think a lot of it is an intrinsic motivation that is different from person to person.

It’s good to have computer science fundamentals—that’s helpful. But, for instance, there’s a guy on our team (hi, Ryan) who was a philosophy major in college and was always fascinated with computer science. He’s the kind of person who is up at night reading papers about programming language theory. I think if he didn’t go to college, he would probably be the same exact way, with the same skills.

There’s a proliferation of bootcamps and training programs, and the people who come out of those are super capable. A lot of them go on to do really amazing things. I think college is useful for a whole host of other things, but it’s not necessary to become a programmer. The most valuable things I learned in college weren’t directly related to my work now. It was more about expanding my worldview, making friends and connections, and learning to be independent.

If you think about it, you’re in college for four years, and then you spend how many years developing and growing in your career? The best people are learning as they go, learning for the job, or learning just because they love learning.

Ha! Well, I'm not sure that this advice would have done me any good because I often still forget to follow it, but here goes:

It’s easy to make things more complicated than they need to be, in anything. There’s a tendency to view the unknown as magical, to assume the elements you don’t understand are really complicated. As a result, it’s easy to overcomplicate your problem-solving.

With Wistia, there were plenty of places where we assumed things were more complicated than they were, and so we created over-complicated solutions to match, instead of stepping back and evaluating. What you’re trying to do is probably not as complicated as you’re making it out to be.

For instance, when we raised some angel money, we suddenly thought we had entered a new, more serious echelon of business. And so we started playing office—we felt we had to be more professional, hold mock board meetings, etc. We found ourselves waiting until those official meetings to make big decisions instead of following our instincts and just solving problems as they came up with the team. It was ridiculous and got to a point where we finally asked ourselves: “Why are we doing this? We’re making this harder than it has to be.”

It’s good to have that moment of clarity. Don’t let the expectation of complexity cloud the problem in front of you.