Ep. 022: The School of Hard Knocks - From Cubicle to Code Master | w/ Special Guest Alexander Savenok of Rig Technologies

You're listening to another episode of Open Source CXO, the podcast designed to share insights on how to excel in your business using technology, regardless of the industry. Host Robert Kehoe is a self-taught software developer who has grown to the role of CEO. Renowned for his collaborations with organizations such as Stanford University, Nelnet, and Louis Vuitton, he continually seeks new challenges to conquer in the world of tech. Joining him is Don Blackburn, a veteran COO with over 25 years of experience in cultivating diverse relationships and driving innovation in various technical projects.

Each week, they'll be sitting down with some of the nation's foremost technology leaders to develop an open source playbook, drawing from their firsthand experiences in the field. Let's talk some tech. Well getting started today for this episode, I wanted to point out that Robert is on vacation now that we're in the summer months. And filling in for Robert is David Welch.

Dave is one of our directors at Active Logic and all around good guy and podcast veteran himself. Correct? YouTube? Not podcast.

I don't talk to other people. I just talk to myself. Just talk to the camera. I got you.

All right. He imagines the people. Exactly. And our guest today is Alex Savinoch, who is CEO, CTO of RIG, who's a startup SaaS product.

Yes. SaaS product marketplace play, similar to Uber, focused on breakdowns in the tracking space. So outstanding. And welcome, by the way, to our podcast.

I appreciate you taking the time to talk to us. I think when you and I were talking a couple of weeks ago about what you did prior to this, which was Vertigo. Yeah. Not trucking.

Totally not trucking. Totally not trucking. So Vertigo was a company much like Spotify. Is that fair?

No. It was a social... Music streaming. Music streaming, but we actually...

It was kind of like... The closest thing I would say is like... You remember Periscope, people do live streams, but it was about getting people to listen together. So co-listening and what people now call watch parties.

We actually coined the phrase listening party, and then that got reused by other people when COVID hit and it became watch parties and Netflix and other people just started using the name for that specific feature. But yeah, that was...we were trying to build a social network around getting people to listen to music together, chat and listen to music together. Because one of our observations was that whenever you're in a big gathering of people, there's always music playing, but all these social experiences we have online, you never have music.

We feel awkward, like the silence on the Zoom call when no one's talking. You kind of want to fill that in with a playlist or something. So that was the basic idea behind it. There's a lot of technology behind it because whenever you're dealing with music, you need lawyers.

Labels will sue you if you do not use their music correctly. So I had a unique experience as a CTO because I had to understand the EULAs of all the service providers we worked with. So Spotify's EULA. I actually had to read the whole thing.

And Apple Music had to read the whole EULA and how it works, what terms...how do we not get cut off? Because the way our system worked was we'd actually have people sign in with Spotify. We'd match that music to what someone...

let's say someone joins in and they have Apple Music. It's all the same music basically, right? So what we'd do is we'd match, create a system that mapped all the music across different providers. We really only got to Apple on Spotify.

It was supposed to...it was a much more ambitious project. We never really had the time to finish it. We got to Apple and Spotify.

And what would happen is when people would come in to listen together, and let's say someone picked a song from Spotify, we would map that to a song to Apple and Spotify and they could start listening together. And instead of transmitting that song through, let's say, like WebRTC and the audio as audio packets, which by the way would be a really bad way to do it because WebRTC has really bad quality for audio. You should not listen to music over real-time protocols. So anyway, plus it violates a few copyright laws.

So anyway, you don't want to do that because it creates actual broadcasts, right? That's actually what radio stations do. They transmit audio over a large space and it's a single audio file, right? It's a single stream of music and you have to pay performance royalties for that.

There's sound exchange exists specifically to standardize the royalties for radio stations for playing music and all that kind of stuff. So in our case, in order to avoid that, we required that everyone who came in, if they wanted to listen to music, they had to bring in their own Spotify, their own streaming provider. So they're already paying for it. They're already paying for it.

And whenever they would listen together, instead of combining the audio and video together, those two files were never combined and you could never reproduce them. So there's another type of copyright right called a sync license. In that case, if you ever have video and audio playing in sync together in a reproducible format, you have to pay a different set of royalties. So we avoided those two royalties.

And funny thing is, on the sync royalties, we had an attorney tell us that we were 50-50. There was a 50-50 chance that we could either lose or win a lawsuit if we took it to court and we're like, okay, that's good enough. 50-50 is good enough. We're going to take it.

Roll the dice. Roll the dice and we went with it. So that was a startup, but that lasted a long time. Was it 10 years?

Yeah. You were CTO for eight years? Yeah. So the technology behind it is actually still being used by a company called Remedy.

But it's mostly being used for sharing when the label shares a song on their website or on a social media post. They now use the mapping techniques to, let's say they share a music video and they want to have the user actually hear that song from Spotify because they get paid more if you hear it from Spotify instead of YouTube. So they create, they have a video synchronizing algorithm that I developed that allows them to synchronize the audio stream with the video without requiring that they're playing together.

It's actually based on WebRTC's audio synchronization algorithm. You may not know this, but your audio packets from WebRTC come in as a separate stream from your videos. And the way they synchronize them is a dynamic playback, right? You watch your video all of a sudden speed up on Zoom.

It's because when you hear audio speed up, you hear significant distortion. It's like your audio gets super squeaky when it plays fast or you sound like you're the Hulk when it's slower. So with video, you can speed it up, slow it down, and people usually don't notice that much. So what they do is they'll slow down the playback a little bit in tiny fractions to match where the audio packets are.

Interesting. And from a tech perspective, you not only were there eight years, but this got pretty big. Yeah. How many developers did you have?

About 30 developers. 30 developers? Yeah. That wasn't here, right?

No, it was about 10 developers in Kansas City. Oh, okay. So it works here. Okay.

No, it was half here, 30% here, 60% overseas. Okay. So we did kind of did a hybrid thing. What was the tech stack?

What kind of technology did you use? Java on the back. Okay. So our backend was a microservice architecture.

Looking back at it, I'd probably still do it as a microservice architecture again, because the unique thing with social media apps is specifically in live events, you have tent pull moments, but there's only one specific part or two specific parts of the services that need to scale significantly versus, for instance, your authentication doesn't need to scale with and say, yeah, you're a commenting service. So the way we were, what we were building, I think a microservice architecture made sense, but it definitely made things complicated to maintain.

And we had Java in some places, we had Node in other places, we even had Haskell in some places. And the reason we chose Haskell was because we chose Haskell before AWS actually provided a, you could get by an instance, but you couldn't, they didn't really have Kubernetes back then. The Kubernetes is a service which is like Lambda, the Google Cloud Run or Google Apps, like that type of infrastructure didn't exist. So in order to create a scalable social media experience that could handle significant influencers that we had several artists that were trying to use our app, we kind of needed to squeeze out every bit of efficiency from our computers and as computational power as possible.

So we went for something functional that eventually once all this stuff got released, you had your Lambda, it became kind of a pain to maintain, you didn't need that, you could have written it in Node, but if only I knew the future. So that's kind of one of those unique experiences, you never really understand why someone made a decision unless you were with them in that point in time. You can look into the past and think that the solutions you have today were available yesterday and oftentimes they weren't.

And you're stuck with a different solution and people are looking, hey, why'd you do this? Well, let me tell you a story. And then once you're five years down the path, it's hard to pivot, I'm guessing. Oh yeah, of course, it's not easy to pivot.

So it's harder to pivot once you already have invested into a specific type of architecture, changing it or rewriting it. Rewrites are probably one of the more dangerous things a company can do because they add zero value to the user and lots of money. And unless you have lots of money, what's most likely going to happen is you're going to rewrite, you're going to have maybe the same exact problems and the same user experience. Maybe once you're done with the rewrite, your user experience is likely going to drop for the first month or two while you're correcting all those bugs you forgot about while you're rewriting.

And then you're going to realize, hey, this rewrite was maybe not worth the 5% improvement I got. So and even thinking about not knowing the future, right? Sometimes let's say you rewrite it to work with Lambda and Lambda fails. They get rid of it in three years because it's not really what they're trying to do.

One of the reasons I've kind of made sure to build everything in Docker recently is at least, I mean, maybe Docker is going to fail, but I mean, maybe, but it's being supported by a good chunk of people in this open source project. And at least I could take that to Google, Amazon, wherever I've been a little more, tried to build in a more platform agnostic way. So yeah, I mean, those are the CTO days of, there's a lot in there. Vertigo was a very interesting experience.

I learned a lot from just mistakes we made. I think one of our biggest mistakes from my perspective as CTO is that I didn't have control of the product. And that was really difficult because you're expected to deliver a product on time, but you can't actually control the scope. And that makes it almost impossible to deliver anything on time.

Yeah, it was pretty messed up. That look you're giving me, it was definitely worth it. I'm confused. Yeah, so I could not control scope because the, so I wasn't, I founded the company, but I asked someone else to be the CEO and he was really, really interested in making sure the product was pixel perfect exactly how he wanted it.

And I could be upset at him, but he died in a heart attack. So I can't even, he and I kind of made up and talked through our problems before he died, but he suddenly died of a heart attack. So I mean, the story of Vertigo ends in pretty dramatic fashion. He's the one dying in a heart attack and it was pretty shocking.

Wow. So he would just change, the scope was constantly changed. It was a moving target. It was, you'd be developing towards a certain goal and then that goal would change.

Yeah, well when you talk about the MVP, that's when I came up with the idea of how big of a mistake do you want to make? You're like, we're making $10 million mistakes. It's not a good type of, it's not throw away. So that's one of the primary things I kind of learned was make sure you have your scope in control as CTO and your tech team is in control of the scope.

Because if it's not, then there's really no one in responsible because the people who think they're designing everything, they can't build it and they can't tell you what it's going to get delivered. But then the people who are building it can't really control what it is. So there's really nobody responsible who actually can be responsible for the timeline. That just leaves a company without the ability to deliver and do one of the most important functions of a tech company, which is iterate quickly.

Because you can't deliver as you expect because you can't... You're always pivoting. One part of the company can't control the scope. The other part of the company can't predict or understand how to build it.

And so you've split it and now no one actually has the baby. Right. Was that CEO technical in his own right or totally not technical? No, marketing guy.

Definitely really a marketer. I learned a lot from him when it comes to how to market, understanding marketing in general because one of the things I think people don't understand about marketing, especially tech people, is how emotional marketing is. And it's really about how people feel. It's about how a person feels in the moment.

Yeah, there are metrics involved, but you have to involve people's emotions and problems and address those in a way that connects with them. And he was really good at that. He was really good at understanding how to build up hype and all that kind of stuff. Amazing business development officer.

I think we had big machine records on our board. We had connections to all kinds of labels. We had the founding member of Insync, the original manager of Insync and Backstreet Boys, who was actually one guy, who helped do our business development outreach to artists. We had a pretty sweet, he was really good at outreach marketing.

He just, what happened with him from my perspective is in his previous experiences, he had released products that he believed were inferior because he wasn't in control of them. And he believed they hurt his company in the long run. And maybe they did because as a non-tech guy, it's really difficult because either you have to trust someone that you know is going to deliver a high quality product quickly or you have to be able to do it yourself. And that trust that he had in someone in a previous company got broken, so he couldn't give it to me and attend this new company.

Which is very tough. Yeah, tough. I mean, the way that people deal with their scars is really interesting sometimes. It's easy to turn a person into like a bad guy.

Really he's a human being who had bad experiences that caused him to make bad decisions based on his feelings about a certain decision. Looking back on that experience, what would you, let's say you're redoing it, what maybe would you change in how you have that set up? Just learning from not having control, what might you change in how that was? Just changing the way that the product is developed, I think would probably increase our chance of success significantly.

The other thing is, I think that was one of the primary things. We had eight years to iterate and we didn't iterate that quickly. It took us a year or two often to modify and change, go from one, often it was six months, but go from one iteration to the other. For a startup that's a long iterative cycle, you have to be able to iterate over a month or two max versus six months a year.

That's too long. With eight years, we should have iterated through a lot more variations of what we wanted to do. I can't go back and identify any other thing that was... I could say, oh, I wish we addressed this market, but honestly it may have failed just because of the other one.

Exactly. You can't really say, hey, I wish we went into this market and did this because it's the same reason you can't say this product is going to succeed because you haven't tested it. It's just a hypothesis. It's untested.

But what I do know and what I have tested is when a product is being developed with no one in control of the scope or the delivery, it's going to really hurt. It's going to fail. I can't look back and be like, okay, I wish we did this instead of that. What I can say is there were process problems that if corrected would have given us a significantly higher chance of success.

Gotcha. One last thing I wanted to... A recurring theme that we have in our podcast is how did you get here, a question, which is how did you get to be a CTO and now a CEO? Did you start off when you were 18 years old where you're going, you know what, I really want to get into IT, I want to be a CTO, I want to manage large organizations or were you like...

I actually started as an intern at HSBC Risk USA and I got bored. I spent three months there and I did not want to live in a cubicle anymore and I realized that the office life was not for me. I also went to a bank and I realized that 50% of the people working there were really copying and pasting from one Excel spreadsheet to the other. When I came in with my macro experience with VBScript, I was like...

Everyone was asking about it. I was like, hey, do this. Make a copy this over here and do this. I was just sitting there and programming.

I just realized that the world is very inefficient and that programming can help a lot. I had an idea. My wife had a problem. She needed to synchronize her music constantly.

That started the music synchronization. It was actually how I started Vertigo. We were going to do file matching at first. That morphed into listening together because matching files morphed into mapping music across providers.

Once we've mapped music across providers, you can now do a streaming watch party. You can add video to it. You can add a chat to it. All those things began to evolve.

How I started was I got bored working in an office. Were you self-taught on the development side? Yeah, taught myself. Taught yourself how to program?

Honestly, I learned... When I became CTO, I only knew how to program in PHP, which is the single language I hate the most. It does not make sense as a language in general. Most other languages are built for humans.

It's not like a unique... PHP is weird. Of all the languages I've studied, PHP... I think Perl is PHP, maybe a little bit.

The way it's syntax is just... It's not the same. It's weird. That's what I started programming with.

When I went into JavaScript, I'm like, oh, wait, this is easier to understand. Now everything's easier. I've done work in C, Java, Haskell, C++, Swift, Kotlin, but also touched... It's done C Sharp, Node, and then all the stuff that comes with Node, React, whatever.

Touched a lot. Most of this was stuff I picked up as CTO because all the people around me were much smarter than me. The one thing I think I did well was hire people far more intelligent than I am. I learned from them.

I came in with PHP. That's all I had. I ended my... The one Vertigo ended, I knew how to program in Java, C++, C, Haskell.

We did Scala. I knew how to do big data stuff with Spark. I done microservice architectures, all of that. All I learned to do it...

The thing I learned, I learned doing this, did it all in the... But learned it all in the flood. I started it, started with PHP. All self-taught, all in the flood.

A lot of times you just got to go for it. You're not going to learn everything anyway. It kind of feels that way in IT. Maybe getting a boot camp or a degree, go to college, learn your first language, but then after that, once you get into it, it seems like...

We all come in with a significant amount of ignorance. The difference between a guy who has a CS degree and a guy who's self-taught is maybe 10%. A CS guy doesn't have that much more knowledge because the way the real world works with programming is nothing. Not like what they teach in the university?

He got syntax, maybe some theory. He learned how a compiler works. He learned how memory works. But ultimately, he doesn't even need to know how the compiler or the memory work.

All that information was useless. It was put in to create a curriculum, but the stuff he needed to know, he maybe learned 10%, 20% of what he really needed to. That knowledge is pretty... Really what you need is a basis because technology is changing so fast that what you learn today is going to be obsolete in 10 years.

You've got to be constantly evolving. You constantly have to. I think for me, that was when I hired developers. That was the thing I valued the most is if I saw a person who was willing to learn and willing to try new things, that person was far more valuable in my company than anyone else because I had learned from experience that...

This goes back to my thoughts on rewrites. Rewriting almost any part of your stack will usually take six months. Learning a language, having a base of a different language takes three months. All you need is someone who's willing to take the jump and it costs much less because we had parts in our tech stack that were unique languages that people could do.

Okay, we could either rewrite this or someone can learn it. I couldn't get someone to learn it, so I had to rewrite it. I couldn't find a person to... I learned it myself.

I taught myself Haskell so I could maintain it, but I couldn't find, at the time, find anyone else who would be willing to learn Haskell, so we had to rewrite it. I think there's quite a few developers that get locked into a certain tech stack and they want to stay there. Yeah, it's comfortable. It's a comfort thing and they don't have to stretch their limitations.

What I realize is people value comfort a lot more. The comfort doesn't produce much. It doesn't make you wealthier. It doesn't help your income increase.

It may seem like the end goal in life, but ultimately you get bored. You stay too comfortable, you get bored. It leads to boredom. I've always found that living in that little comfortable space is...

I mean, I've started to tech start-ups. I was going to say, that's why you keep going into start-ups. I just don't like... Boredom was the primary reason I couldn't handle going to HSBC risk for another day and staring at a cubicle and working with Lotus Notes.

This was 2005 and I was still working with Lotus Notes. That should tell you how advanced things were. Exactly.