Since its start in 2005, Vidyard–a company which provides online video hosting for business–has grown from a team of 2 to over 200. Its 4 million users create over 60,000 videos each month.
Commit co-founder Beier Cai sat down with Devon Galloway, co-founder and CTO of Vidyard, to talk about the early days there and what it was like to write the first lines of code.
Beier Cai: How did you get into the tech industry? And what was the first software you wrote?
Devon Galloway: I was always interested in programming, and I did a bit of it in elementary school and high school. My dad worked for a big insurance company—I was in high school at the time—and they were sending out client bills by email. It was all B2B stuff. Big, big client bills.
They had a spreadsheet for every client with the bill number and the email address to send the bill to. They employed two people to do this every month. All the bills would go into a folder and these people’s job was to send out the bill in an email with the form template email. My dad was telling me about this and I was like, I think that’s something a software program could do. And again, I was a high school student. So I was like, let me try learning about this and see if I can do it.
I built a macro that sat on top of the Excel spreadsheet. I wrote it in Visual Basic. I did it in a weekend and I showed it to my dad, then we went down the list and emailed the bills out to those email addresses with the form, and he’s like, oh my God, this is a miracle.
We took it to his boss at the insurance company and they said, This is great! The biggest problem, though, was that those people sending the emails make mistakes. They send the wrong client bill to the wrong customer. And I was like, the program won’t make mistakes, it’s going to send it to the right person. As long as the spreadsheet’s right.
I gave it to them, and I’ll never forget, my dad’s like, my boss feels like we should give you something, but they can’t pay you. So I got what every 16-year-old boy wants: a $100 gift certificate to a grocery store.
Beier: Did that experience inspire you to get into the software industry?
Devon: Not so much in software engineering, but in making things. I’m really big into airplanes—I used to build all these remote control airplanes. I actually went into engineering school thinking I wanted to build robots, that kind of stuff. From that experience I went to the University of Waterloo, did a lot of co-op programs, and I went down the path of IT, then pivoted from traditional IT to writing code.
At one of my first IT jobs, they said to me in my first week that my job was to send people emails asking them to fill out fields in this system the company had. So I pulled up my old Visual Basic tool to do it. I used the exact same thing to send emails there too. They were expecting me to just spend my whole four-month co-op term typing up these emails.
Over and over again in co-op terms, having a software toolset and the ability to write some code always helped me. Then when we started Vidyard I got even more into that side of things.
Beier: You were in your twenties when you began building Vidyard, if I’m not mistaken. What made you decide to start your own company?
Devon: Again, it was a co-op term. My cofounder Mike Litt and I were working at Blackberry, and we saw a problem. I’ve said this to many, many entrepreneurs through the years: I don’t think the best reason to start a tech company is because you want to be an entrepreneur. It’s because you see a problem, and a company is the best way to solve it.
We started as a video production firm. We saw what Blackberry was paying another firm to do terrible work, really expensively, and we thought we could do it so much better. We thought we could do a couple projects every year and go skiing and enjoy our summers and live a cool lifestyle. It was more about that than wanting to start a massive business.
We’d make videos and the companies would ask, what do you suggest we do with this? The answer at the time was YouTube, but there were problems for businesses on YouTube, like ads. And the videos would be on YouTube.com, not on our client’s homepage. So we saw this problem, that there was lots of video production companies but no one was solving these issues for businesses and we thought we could do that best.
Beier: A lot of engineers thinking about starting their own companies are worried about financial risks and career risks. There’s a fear of missing out on more stable career growth. How did you balance those risks when you transitioned to Vidyard?
Devon: On the financial risk side of things it was probably naivety. We started the company while I was in school, and when I graduated the company was still very young, so I took a job at Blackberry and moonlighted on Vidyard.
Long story short: I took a financial risk to leave that job, but I just super naïve. I was, like, 24. My mom told me I was leaving a really secure job at Blackberry, but nearly everybody in my department was laid off a couple years later. I was fresh out of school and I lived with all my roommates from school. We lived for, like, 300 bucks a month, I I felt that I could take a financial risk because I didn’t have a lot of expenses and mortgage that come later in life.
Beier: When you started Vidyard, how did you make your technology stack choices?
Devon: The biggest thing that played into it was the open-source community. We ended up being a Ruby on Rails company — we wanted to build what makes sense for us, and we want to be able to leverage open source and great libraries and stuff like that for pieces of the product that we don’t want to optimize. Ruby was and still is a super-active open-source community, with client libraries for everything. It just felt like we could be most productive in it.
Beier: Did you know Ruby before you used it?
Devon: No. We had three engineers at the time, and one of them was a really experienced Ruby developer and the others weren’t. But it was okay, we didn’t have overlap where all three of us were super experienced in the same tech stacks. We knew someone’s going to have to learn something new. With Ruby, we felt like we could get up and running with it really quickly.
The last piece I want to mention in terms of what went into the decision was knowing we could recruit developers to work in Ruby. One of the big reasons we knew it wasn’t going to be Java was that it just wouldn’t be interesting to other devs. We’re probably not going to be able to hire a ton of super experienced Ruby devs because it’s new, but people will be excited to learn it and for a good software dev, the language is not a barrier by any means.
Beier: In early days, what kind of constraints did you find really helpful while you were building your software? For example, there’s the business constraint where you’ve got to move fast. What sort of concrete constraints helped you build successful software on time and on budget, and at a high quality?
Devon: We went through Y Combinator, the accelerator program. That introduces a couple of constraints around when we needed to ship by. YC’s really useful if you have a product in market before their demo day. And less so if you don’t. Especially in those days. So for us, we knew we needed to ship before the end of August, 2011.
From April to August there were four of us working on the product. We knew the very basic scope of an online video platform was to host a video and play it on the internet. The scope was pretty clear for us. It’s like, we’ve got to play a video or have it on the internet. And the timeline was pretty obvious too. It was pretty clear what we had to do.
Beier: Have you always had a clear technology vision? Like, this is where we should be in the future? Or did you let it happen organically?
Devon: We kind of built a framework a couple of years in. The early days are just following customer demand and looking for revenue anywhere you can find it. Those really scrappy early days for sure. I think post–Series A is when we said, okay, what’s Vidyard’s role in the world?
I remember in our seed round days people were like, you guys should be Instagram for video, because Instagram didn’t do video at the time. And I was like, Instagram should be Instagram for video.
There’s always been fads in video. And there will be fads in any area a startup takes on— areas you could potentially get distracted by or areas of opportunity you could potentially grab or miss. For us I think we did a relatively good job of saying what Vidyard’s role in the world is. Would I love to be Tik Tok right now, to own a $50 billion asset? Yeah, maybe. But I think we were very specific on what our role in the world was.
I do think we’ve underinvested in product management. We got distracted by clients asking us to do a thing, and then we found it didn’t apply to the vast majority of our customer base. When you take on a thing that a particular client’s asking for, it’s one thing to say, how much is this client going to pay, versus how much is it going to cost us to build it?
You have to take into account opportunity costs, maintenance costs, the UX burden on every other one of your clients. So it got us to where we are. But it also introduced a bit of pain in terms of complexity in the product.
Beier: A lot of start-ups make public announcements for major product releases and business milestones, like fundraising, but something that’s not talked about as much are technical milestones. When systems scale 10 times better, or you transition to a modern technology cycle. What’s a major technical milestone you accomplished and how did it happen over time?
Devon: We’ve had a number of iterations on analytics that have all been really big investments. In the earliest days we made a poor choice of our database for video analytics. We chose a database that was trendy at the time, but super early, and it just didn’t scale well. About a year in we were telling everybody we were a video analytics company, video hosting and analytics. Then our analytics stopped working! We were like, shit, we have to replace the whole database tech to fix this. We’re flatfooted, we haven’t been working on this. It kind of came out of left field. It’s going to be six weeks until we have analytics working again.
That should be the kiss of death for a company that’s video-analytics led. But it’s funny, in that whole six weeks it took us to replace the database nobody said anything. None of our customers. We had probably close to a million dollars in annual recurring revenue. A bunch of customers paying us for video analytics. And nobody said a word.
That was probably the scariest thing that ever happened to us. There was a huge identity crisis. You tell everybody you’re video analytics, then you no longer have any analytics, and they all still pay you and they don’t complain. We flew under the radar with our problem, but why do people pay us? Does video analytics actually matter? Why do we have a business?
I know the question was a little bit different, but that one jumps out. What seemed like this massive technical problem actually became a massive identity crisis. All of a sudden the technical problem matters a lot less, We learned a lot about it. I think it actually drove a lot of the business we have today because we learned so much.
Beier: My last question from a technical perspective is about managing technical debt. As you grew to hundreds of people and a much larger scale, how do you balance technical debt, product innovation and keeping the lights on?
Devon: We’ve gone through a couple of iterations of this. Until about three years ago we had this process — one of our earliest engineers, our VP engineering, calls it Refactor-geddon, but every Christmastime we would devote everything in engineering to product cleanup, to refactor tech debt. Outside of burning hot fires that had to be fixed immediately, most of the time we’d keep a board going of areas we’d like to invest more in, and we’d save that for Refactor-geddon.
That worked for a number of years. But it forced us to only take on six-week projects. Because then we’d kind of be back to innovation. So the really looming stuff — probably the biggest one being UX, and we had to do a huge UX refactor — that would never have gotten done in that period of time. So we had to change our approach to it.
We coupled this with changing our engineering team structure. We created an engineering role called tech lead. Tech leads are responsible for certain areas of the platform. They’re like product managers, but they own an area of the platform from a tech debt maintainability perspective. It doesn’t mean they’re responsible for doing maintenance all the time, but they’re responsible for identifying the things we can’t sacrifice on.
We still have a Refactor-geddon thing, but it’s built into the daily work of our team. We call it 30 percent time. Thirty percent time is your collaboration time, but it’s for tech debt maintainability, performance, all that kind of stuff.
Beier: I want to switch gears, to the people side of things. In the very early days, did you have a hiring strategy for the first few engineers you hired? What qualities were you’re looking for? What worked and what didn’t work?
Devon: The early days for us were truly startup-founder-mode, where we were all living in a house together. You’re living, eating, breathing work. There’s a certain kind of person that can live that lifestyle. Ultimately, you know, it’s not going to work for folks who have families or lives. The early, early days were like that, and it was mostly friends from school who we brought in.
In the earliest days, it wasn’t rocket science for the product. We’re not an AI company. We’re not a MedTech company. It was pretty standard web dev. So it was more important that we have generalists who can take a project from beginning to end, and somebody who doesn’t have a ton of ego and wants to solve really big scaling problems or really big technical complexity problems. Because we didn’t have a ton of that stuff.
We knew retention of our staff was going to be really important. We’re really lucky, we’re in Waterloo. There’s an amazing pipeline of students from the universities. So we were able to hire a lot of great ex co-ops or folks early in their careers who didn’t have that ego, who wanted to be a generalist and wanted to get in on the ground floor of something. That was our early hiring practice.
When we were about six or seven people I realized we’re really light on experience — we think about this business scaling and needing to build some structure around it. I was really young and needed some experience around me. So we brought in a couple more folks with a bit more experience, and that brought amazing dividends.
Beier: What’s your advice to younger founders with less technical experience hiring much more experienced engineers? Those experienced engineers bring expertise, but now they’re reporting to a younger founder — what’s your advice to manage that relationship?
Devon: It’s funny, I’ve had couple of periods where I’ve interviewed former bosses from co-op jobs, and there’s definitely a transition of roles there. For me, I’ve always tried to focus on my strengths and think about what we can augment on the team. I don’t need a ton of people who are just like me. I’d rather have people who are smarter than me at the areas we need help.
I often describe the role of a CTO as having four key components: people, process, product and codebase. With those four things in mind, what was my strength going to be? Where did I want to focus? And how do I augment the team to fill in for my weaknesses.
I’ve always been really up front with people who come with more experience. We’re hiring them for that experience and I want to play to that. I don’t want to have any ego, to think that I’m better at it than them. In fact I’d rather they be better at it than me, otherwise I wouldn’t have them join our team.