The Data Stack Show - 06: The Technical Challenges and Opportunities of Building a Startup Inside a Large Bank with Sam Bledsoe of Ruby

Episode Date: September 16, 2020

This week on The Data Stack Show, Kostas Pardalis and Eric Dodds continue their conversation about Ruby, a start-up designed to help families navigate their financial situation in some of life’s most challenging moments, by talking with the Nashville company’s CTO Sam Bledsoe. This follow-up discussion digs into how their data engineering and marketing setups co-exist and how they rely on Azure.Sam’s background and more info about Ruby (2:11)Privacy-related challenges at the intersection of banking and medical data (4:33)What to expect from using Azure (15:06)Breaking down the stack (24:44)The need for marketing people with technological skills (36:20)Talking Big Query, RedShift, Spark and data virtualization (41:15)Biggest changes anticipated in moving as a spin-off from the bank (43:59)The Data Stack Show is a weekly podcast powered by RudderStack. Each week we’ll talk to data engineers, analysts, and data scientists about their experience around building and maintaining data infrastructure, delivering data and data products, and driving better outcomes across their businesses with data.RudderStack helps businesses make the most out of their customer data while ensuring data privacy and security. To learn more about RudderStack visit rudderstack.com.

I'm talking to Nick, who runs the data infrastructure on the marketing side of the house. And today we're going to talk with Sam, who's the CTO of the company. And I think I'm interested in hearing about Nick has done so much, as we heard in our previous episode around data infrastructure. I'm really interested to hear Sam's perspective on what that's meant for him as the CTO. Has that actually allowed them to move faster as a product team, not having to deal with as much of that sort of pre-product data flow? Costas, as an engineer, what do you want to ask Sam? What are the

questions in your mind? Yeah, I'm very excited about our conversation today, mainly because it's our first chance to actually hear the different stories from the same company. Like, as you said, we had Nick last week, and he shared his perspective, his experience from marketing, and now we can see also the perspective of engineering. I really want to see how engineering works in Ruby, how they operate with marketing, how they figured out how to live together, what are the boundaries in terms of the responsibilities and what that means in terms of the responsibilities and what that means in

terms of like what kind of skills marketing should have like today in order to not survive but like thrive let's say inside especially corporate environment because don't forget that we're talking about the company that is actually a spin-off of a very big and traditional organization like a bank. Yeah. Great. Well, let's dive in and talk with Sam. Welcome, Sam. It's really nice to have you here on part two of our conversation with Ruby. You are the CTO there. And would you like to make a quick introduction about yourself, your background,

and also share a bit more information about the company and where you are right now? Sure, yeah. I've been involved in software since I was about in middle school. I've been doing dev ever since then. All my professional experience is in IT and software. These days I do more management stuff and that includes security and compliance because we're actually part of First Horizon Bank. So I'm an employee of them. They take

security and compliance very seriously, of course. So Ruby is a startup that's inside of First Horizon Bank. We're like a department of the bank. You can think of it like a corporate innovation project. We're in the process of skinning out of the bank, so becoming our own company that's like a normal startup with investment and not subject to the rules of being a part of a bank. So having all our email and stuff run through bank security, that'll be really nice. And our mission is to help families help each other with finances. So the, we built

some products around helping people monitor family finances, especially for aging parents. We built some stuff for helping people organize information in their lives, like insurance information and banking information and medical information, like allergies and stuff for their families and got several thousand people signed up for that. We now, those are web products and we switched to working on like an app based product that it helps

people with medical bills in certain ways because people don't really know what to do when they get medical bills a lot. They're very difficult to deal with and confusing. Yeah, I can feel like almost everyone can relate to that to be honest. So, a quick question

based on the stuff that you shared with us so far. I mean, what I find very interesting about your case is that in terms of the industry that you are, you are really in the intersection of two of the most let's say strict industries when it comes to security, the intersection of two of the most, let's say, strict industries when it comes to security, data privacy, and also being part of a bank.

But even if you were not part of the bank, just by working in the financial sector and also in the medical sector, it has a lot of challenges there. So can you expand a little bit more on that? How this has affected your role there? How it affects the product? How this, I assume, might probably be part of the culture of the company? And what does this mean at the end?

Yeah, for sure. So this is the most, I don't know, peculiar thing about the way that we've started, I would say. We've started as a very small part, just like, I don't know, three full-time employees in a pretty huge bank that has 5,000 or 6,000 employees. And our backgrounds are, the people who got hired for Ruby,

our backgrounds are like small companies and startups and stuff. And nobody else in the bank could really relate to the way that we just thought was normal to do things. Like we had to get started with a cloud account. And I was like, hey, AWS or Azure guys. And like that went all the way up to the CTO, the CIO of the bank. A bunch of people had to like comment on it and get involved.

There's this whole procurement process. And like, you know, vendor risk wanted to negotiate with Microsoft. And I was eventually somebody was like, here's a credit card. Just go do go do it otherwise it's not going to happen and that was pretty accurate so I just went and did it and we spent years cleaning up that decision because sometimes you just have to do stuff otherwise it won't be done but then you know the bureaucracy and the other departmental mechanics have to come and still do all their stuff so that was one example of the kind of stuff we'd have to deal with. But a big deal in the bank is, of course,

risk management, making sure they're compliant and IT security and making sure all of the compliance and risk things are dealt with in security. So that department had a lot to do with how we got started. So we definitely started with some security-first stuff. And I can say that Azure is really good in that respect. So like for people who have to deal with formal security and compliance programs or people who just kind of know what they're looking for with security,

it's got a lot of stuff right out of the box that really helps. And it presents it in a way where it's like kind of all packaged together and like a product like you would expect from Microsoft. So that works really well, but it's also a pain in the ass. Our email, for example, we can only get through this online web proxy, and we can't download attachments from it. If we want to access normal email, they use Outlook, and we have to use these Dells that barely work. I don't know. So we bought our own MacBook Pros, and that works fine for us,

but we can't access a lot of their internal stuff or get on their network with the MacBooks because they're not official assets. And it's hard to tell them sometimes our way of doing things. We don't have a network. We have a bunch of SaaS applications. We have an Azure environment

that's all platform as a service, so there's we have an azure environment that's all um platform as a service so there's no vnet or you know anything like that our email is just a sass thing so you know they're asking how we secure our network like we don't have a network we don't have any special computers or endpoints or anything it's weird man trying to deal with it sam it's interesting the um you know just hearing you talk through that, being the CTO and having to set up all the infrastructure, you hear all the time, and it's really common to hear the cliche

that it's really hard for large organizations to innovate. But that just made it really tangible, right? That trying to do what are really basic things for you are just seem phenomenally difficult. I mean, obviously security is really important for them because they're, you know, dealing with other people's money. But one question. So you mentioned spinning out

and you've had to go through a lot of stuff as far as security, some of which is, you know, sounds like it's overly stringent. But from a technical perspective, since you're dealing, you're also dealing with other, like your users' financial information, what are the things that you're going to take with you, you think, from what you've learned at the bank as you think about what the product will look like outside of the bank? That's a good question. So there's, this breaks down into two major areas

of things you do. And then like sort of a way of thinking, the way of thinking is the risk approach, like a risk-based approach, everything. There's a whole risk department in the bank. There's a chief risk officer. Because banking itself deals a lot with risk, but internally in their corporate decisions, they have to understand this stuff. That type of thinking, which I will tell you does not really come naturally to developers

who are just trying to get an app done and out the door and whatever, is definitely one helpful thing. I don't necessarily lead with it these days, but I can definitely one helpful thing. I mean, it's not, I don't necessarily lead with it these days, but I can definitely rely on it and more of my team can rely on it now that, you know, like you say, we have to take it very seriously because of the type of information we

managed. So the two, the two things that we actually have to do are security and compliance, which are different. And compliance is like when we're formally required to meet some like industry or regulatory or legal guidelines like HIPAA, for example, or there's some bank, there's a SOC 2 type 2 audit that we thought we're gonna have to go with for a while.

It turns out we don't need to be compliant to any health care or or financial regulations of any kind which is very convenient but we did go through an entire exercise of preparing a SOC 2 type 2 compliance program so there are some particular things from that that we will take with us like our access request system the way that like our resources are tagged, for example, in production, the way we monitor changes to access requests and our environment in production, stuff like that, has definitely been really good. But the focus is definitely security.

That's the practical stuff that you do to actually stay safe. A lot of compliance can be like, I don't know, hoops you jump through because 10 years ago, somebody was worried that something in your network could be a problem, but that doesn't even exist today. It's a lot of weird stuff that doesn't even always apply. But security is practical, and we have a ton of good security set up now,

both in terms of pieces of software and ways that our systems are configured and our platforms are configured and our processes as a team, like how we go through thinking about these things and the people we have access to. We have a sort of virtual chief information security officer that we check in with as regularly as we need to about what should we consider when doing this.

They know what white papers to check out and what vendor products might be needed. So it'll mostly be some practices, a little bit of staffing, and a lot of security stuff. For example, in Azure, there's a security information and event management system, a SIEM, called Sentinel. That's great. Some of the systems set up for alerting and approval

around access control, their privileged information, privileged identity management system, their PIM system is fantastic. Some of the stuff in our G Suite for email that we've learned to set up, this kind of stuff. Got it. And just out of curiosity, as the CTO, what security things are you worrying about at Ruby that you wouldn't necessarily worry about if you were, say, building a consumer game or something that just has a basic level of user account and user interaction?

And I'm thinking about our listeners who are maybe working on things that just don't undergo the level of security or compliance rigor that you have to face. Right. So a lot of it is the same stuff. You just worry about it more and you undertake more stringent requirements. There are more of a pain in the ass for your users and developers to gain, you know, a higher level of security. And so that's stuff like making sure it's two-factor auth is turned on everything, by far the most important thing to deal with is accounts,

like user accounts for your customers and also our own internal corporate user accounts. So all the alerting around that, all that is crucial. But since you're dealing with more sensitive data, we make sure that we're up to date on cipher suites and bit lengths for our keys and stuff and our certificates, basic stuff like that,

but it's actually easier to use an old cert or something by accident and get some crappy version of TLS. But it's encrypting the data at rest, too, so we've made sure that some of the Azure features for the SQL Server as a service deal are on for encryption. And the way that we store those encryption keys and their Key Vault service is also, I mean, it better be secure

because it's a huge pain in the ass to access it. And that's generally how key store things work. You have to jump through a lot of hoops to be able to get into it. So those are the major things. And then on technology, and then separation of duties and separation of concerns, making sure that we have

some record of admin accounts being requested, for example, and the person who requested it can approve it. The same person doesn't do dev deployments and requirements, that kind of stuff. Sam, are you deployed only on Azure

or you have a multi-cloud deployment for your services? It's really only Azure. We have accounts with AWS and Google, but they're extremely minimal. AWS, we're going to use it for some backup or something that's in a different cloud, and Google is just for marketing technology. That's interesting. I have more to ask about this but about

Azure mainly because most of the startups out there, it's like quite, it's not that often that you hear them starting with Azure and I don't think that many people have experience about what to expect with Azure. I had some personal experience to be honest.

I mean, when we started Blendo for quite a couple of months, we tried to deploy it there. But, okay, it was also almost five years ago, so probably many things have changed with Azure. And I always had this impression that, okay, it's a very glossy user interface, but many things that do not work very well behind the scenes sometimes.

So can you share a little bit more of your experience with Azure? Like the things that, I mean, you touched already some things that you like that has to do with the security, but also some of the things that you probably hate about it and having also experience with the rest of the cloud providers,

like give some kind of comparison between these. Right. Yeah, good question. So before I got to First Horizon, my only experience was AWS. Like there's no reason to really use anything else. It's fine. It's always worked for me. It works for millions of people, whatever. And when I got to First Horizon,

I'd ask them, do you want to use Microsoft or AWS? And this is a classic example of like large institutional decision making the cio said microsoft because amazon had been in the news a little bit about like considering offering financial services so they viewed them as like a possible competitor nothing to do with the technology or like how easy it was to use or if it would serve the need like to those guys if it has the same list of features and benefits, it's the exact same thing. They see Skype and Zoom as the exact same, for example.

They see Skype and Slack as the exact same because they're both messaging things. So we picked Azure, and I was like, well, whatever. It took long enough to get something picked, so let's just go and try it. So we tried it. And what I'll say is that over the last, I don't know, three or four years, it's gone from just sucking.

It was just a piece of shit to being good. Like it now competes with AWS. The primary, like the way I would describe the difference, somebody, I think it was one of our virtual CISOs or something brought this up. He said, AWS is built on the Linux model where everything is like a small composable tool set. You can think of like piping commands together in Bash or whatever.

And Azure is built on a product model where like everything is sort of productized and like you're saying a little bit more glossy and like full of features and stuff like that. Under the hood, like a still a cloud provider, you can access it online with a console or via API or whatever command line system. But the way this stuff is expressed and packaged and like, you know, sold to you, you can tell that there is that difference in design philosophy. And like these days, Azure is good. Like it works. Every once in a while, there's something that sucks,

but usually like we've run into a couple products that were just bad, like their B2C Active Directory, which is like their OAuth solution, terrible, not ready for commercial saleability whatsoever. But almost everything has done like 80 or 90% of what you'd want and just leaves out a few things that you would kind of want. And a lot of that is on their roadmap. They're responsive in their customer service and support and like understanding like what you're trying to do and helping you do it like that's been pretty cool the major complaint i

would have is probably the documentation which i think is the same thing i would say about aws but they suck in different ways so in aws like what i would notice is the docs would tell you that you could do something and then somewhere buried in there, there was some tiny detail about how you couldn't do one particular thing, and that's exactly what you wanted to do, and I would not notice it on the first read, and then once I got into setting it up, I'd go back and be like, oh, and right here it says it can't do that, damn it.

Just dumb stuff like that. With Azure, it's more like the docs or out of date, or it's hard to find the most recent or correct version. Yeah, that was a great analogy, by the way. I really liked it. I think it's completely to the point. And yeah, I can relate also with the documentation. It's also, I think, one of the reasons

that AWS is easier to work with is because there's also a lot of user-provided content out there about how to work with it, while with Azure, you don't have that much of... It's getting there. Just within the last year or two, I would say the blogs and stuff are getting there too. That's great.

That's great. Cool. You mentioned that you're also using GCP for marketing. What's the reason behind that? Why we decided to have a completely different environment for anything that has to do with your marketing function? For BigQuery, you mean? Google BigQuery?

Yeah. Okay. The way that we've set up our marketing technology is mostly a bunch of like off-the-shelf SaaS stuff. So it's like whatever the marketing team could like, you know, get going and sign up for with a credit card and then hook up some pre-made connector to some other service or whatever.

So segments, like Eric mentioned a good example there, you segment and put things like, I don't know, Hotjar and Customer.io and Amplitude and Mixpanel and whatever. And we'd put the tracking code in our systems and work with them on getting the tracking how they wanted it. But for the most part, their stuff was all plug-and-play. And what Segment happened to plug and play with was BigQuery. So they just used that.

Okay, makes sense. Did you have any kind of implications related to your best practice for security by having to work on multiple different clouds? How did you handle that from a technical perspective? So from the bank's point of view,

data that is strictly marketing data, and these days you have to keep some IP address information out of there for it to meet this requirement, with the way that new California law is working. If it's just marketing data, it has a much lower standard of scrutiny on what you need to be concerned about. So as long as it was just usage data that was not personally identifiable

or anything getting pumped through all these systems, I mean, there was some basic, I mean, there's like account control and, you know, make sure everything's using SSL. But beyond that, it's not a lot to do. Interested, Sam, in the, it sounds like, and I mean, from the conversation we had with Nick, it's clear that marketing has been pretty self-sufficient. I'm interested in your perspective on that. I mean, I know that there are a lot of reports and other things that are distributed around the company. And it sounds like from your perspective, you haven't had to be as hands-on with that. I'd just love to know a little bit about that experience from your perspective as a CTO. That's a tension a lot of times i've seen at startups both you know my own experience but also observing other companies is that especially in the early stage there's this tension between like

i mean modern day marketing is very technical right like you're wiring stuff up there's a ton of front end nightmare that has to be dealt with you're dealing with data on the back end you know all that sort of stuff um i'd just love to to hear about your experience at ruby with that with nix kind of running like a more self-sufficient right practice there uh yeah good question because this did not used to be the way that marketing worked and having worked in a lot of software like you know companies and departments there used to be a lot more i don't know overlap you call it collaboration i guess but we had to work together a lot more um so i think a few things have happened there number one like the state of the art when it comes to like marketing systems online that can like talk to

each other is way ahead of where it was even like I don't know five years ago. Like the number of products that can talk to each other and have reasonable use cases and pretty much do what you would expect when you plug them into each other has exploded and they've become easy enough to use. Amplitude is really complicated for example but there's things like it like Mixpanel that are really easy to use. And when I say easy I mean easy for someone like me which brings me to is really complicated, for example, but there's things like it, like Mixpanel, that are really easy to use. And when I say easy,

I mean easy for someone like me, which brings me to the second thing that I think has changed or contributes to this, which is Nick has just done a lot of this stuff. He has taken some classes in Python and SQL and stuff, and he can do basic technical stuff. So you need

somebody like that on the marketing side to like figure out which api key goes where and you know stuff like that some basic literacy and even a little bit more than that sometimes uh but that's what it takes on the marketing team like you can't just have data analysis analysis and like people who do you know add strategy and copy and stuff anymore like you have to they have to know how to do some of that stuff and of course i have to i don't know put in dns records or like help with some uh redirect thing when it's not working or whatever but like it's really pretty minimal like sometimes it's more at the outset um to get some stuff set up like those that department really is self-sufficient it's because of the tools and i think the last thing uh the last

component is that my own personal approach to it is to. It's because of the tools. And I think the last thing, the last component, is that my own personal approach to it is to stay as far out of the marketing technology as possible. Like, it's not what we're building. It's not what we need to build. These days, the off-the-shelf stuff is great. So even if they have to pay some fee for WordPress hosting or whatever, I'm not going to host WordPress in Azure

because I don't want to reset it when MySQL goes down or whatever. Like, it's just not part of what we need to do. So we've stayed pretty hardline about that and it's worked pretty well. That's very interesting. It's also my experience that I have so far with technical teams.

I think this kind of separation of concerns between the technical team that you have for your product, like the engineering team that you have for product, and any kind of technical support or IT support that you need for your product, like the engineering team that you have for product and any kind of technical support or IT support that you need for other functions, I think Separate is a very good strategy. And I think this is one of the reasons

that we also see some roles arising, like marketing ops, sales ops people, that mainly their job is to do that, like make sure that they are literate enough technically so they can take care of integrating all these different systems and putting all these technologies together.

So, yeah, that's great to hear. Sam, can you share a bit more information about the stack that you are using right now and building your product? So the first things that we built, the first two products we built are web apps. And on the front end, we use Vue.js

with I think SaaS and Pug and a WebKit tool chain. It's a pretty standard front end application just using Vue. Vue's worked out great for us. All that communicates with some stuff hosted in Azure. So that's C Sharp running on Azure's platform as a service app services thing. Microsoft just names everything like what you would call it. So their app service hosting

is just app services, which is annoying sometimes. So that's, that all works exactly like you would think it's very easy to like deploy to there's a, you know. We use an app service thing, a database platform as a service thing, and Microsoft's version of S3, which is blob storage, they call it, Azure storage, like you would think. The SQL Server platform as a service hosting is called SQL Server.

So that all works pretty much like you would want it. And enough people on the team had a pretty good amount of experience with having to like deal with IIS and Microsoft SQL Server and, you know, SMB file shares and all that crap that we knew what we were looking for and how to set it up.

And they make it easy to do. We also use a couple of ancillary tools like Azure DevOps is there. It's got a board and a build systems and deploy systems that are all integrated with app services stuff to deploy to and do database migrations and stuff. Works well. For our more recent application, we're using Xamarin Forms

and Microsoft has something called App Center, which used to not really have enough features to be usable, but these days works pretty well, and it does your builds, and it can run tests on emulated devices for you, and it can push out to the Google, the Play stores. It's pretty good. We have a lot of other random stuff like our antivirus and endpoint protection and stuff is also through Microsoft, but it's not really as interesting.

Yeah, it's very interesting. I mean, okay, you're obviously like a Microsoft shop in the sense that you're using Azure and also all the technologies that are associated with it. How did you choose the stack? Let's say the selection of the stack came after figuring out that you have to be hosted on Azure or vice versa.

And how was this driven mainly from the requirements that the bank had, for example, because you had to follow some kind of guidelines from there? How did you choose that? All right, good question. So the C Sharp stuff, like the Microsoft backend stuff, is because I was working at a consultancy at the time and we did a lot of.NET work

because Nashville has a lot of.NET work because of the hospital chains and healthcare companies that are here, they use a lot of that stuff. So these days with like the Microsoft MVC and MVVM and some improvements to C Sharp that have been made to make it a little more like dynamic, like dynamically typed and less rigid, it works pretty well. Like it's a pretty solid language.

It runs on lots of platforms. So we picked, we were pretty sure we were going to use C Sharp, not 100% sure, but pretty sure. Started hiring people. It looked like, yeah, C Sharp developers would be probably the easiest thing to get in this area. We waited until we hired to pick out the front-end framework, and the developers, you know, we got together and said,

like, let's use Vue, and, you know, it looked mature enough for us to go for, so we did, and it's worked well. And I described the Azure choice. It was like weird bank politics that luckily worked out well. Yeah. Based on your experience, I mean, okay, it sounds like a natural choice if you are on Azure

to build your product with the rest of the Microsoft stack. Do you think there would be a difference if you used a different stack and not Microsoft products and being on Azure? Somewhat. I built some services just to hook up. We use Slack and Notion, and I built some services to hook up Slack and Notion,

like a type of Azure function type thing, but in, sorry, what do they call them? Lambda, AWS Lambda thing. They're called Azure functions. And I built that in Python. So I got a bit of, you know, intro to like how some non-Microsoft platform stuff works. And it usually works fine.

It's not always as like up to date, like, you know like framework version-wise, but you can deploy a lot of different language and framework environments to their services and still do your web apps, and pretty much, I mean, not whatever you want, but I think they have Node and Python and Java plus C Sharp these days. Don't quote me on that.

I guess I'm being recorded, but I think that's what it does. Back-end-wise, I'm pretty sure you can do non-SQL server stuff. I know they have a thing like Mongo or whatever that's a document store, but I think you can do Postgres and stuff even in their

systems, and not all the features work. You can't do all your backup and replication groups as tightly as you can with SQL Server, but they do make that stuff basically work. Yeah. And what's it based on your experience? Do you think the opposite

also works, like having the Microsoft stack but being on a different cloud like on Google Cloud Engine, for example, or AWS? I don't know about Google, but it works fine on AWS. It's a little weird to have to have VMs for everything, or you used to have to have VMs for almost everything. And it's not nearly as natural as deploying Node code

and Python and stuff up to some of the AWS services, which is way more natural and easy, I think. But I actually don't know where AWS has gotten with Mono or whatever the common runtime is they're going for these days, which seems like it'd make it a lot

easier because the same runtime they're going for running that on all platforms, so like Linux and Windows and Mac. I don't know. I don't have a good answer on that one. Yeah. From my experience, the only thing that I have been exposed to is using MS SQL on

RDS, which, okay, of course it works pretty well. But I never had the... I have never experienced building or deploying CSR publications, for example, on AWS. I was very curious to hear about that, because I think that's also something that's pretty unique with Microsoft. You have the full stack.

You have the cloud infrastructure. Then you have all the rest of the stack there. And they, of course, build everything to work perfectly together. So it's interesting to see what kind of other options there are there. Cool. So next question. Okay, you mentioned what you're doing and what technology you're using for your product stack, your technology stack.

When it comes to data and what kind of data you are doing and what technology you are using for your product stack, your technology stack. When it comes to data and what kind of data you are collecting and how you use that, I mean, of course, you are doing that for marketing and you are sending these to Google for further analysis from the marketing team. Is there other functions inside the company that they use data and what's the infrastructure in the stack that you use to work with your data? Right. Okay. So outside of like, you know, operation, like technical hosting the website and marketing,

it's pretty much product. Sometimes our like customer service ops, people look at some data about like requests or whatever, but it's really not that prevalent. They use Zendesk and it works fine. But product generates and consumes a lot of data. So we would track pretty much whatever people do as they come to the site and products will look at that in terms of sometimes heat maps,

but a lot of like user flows and trying to get an understanding of what people do when they come to the site, of course, and what features and flows they go through, that kind of stuff, user numbers based on platforms and OS and all that kind of stuff you'd normally expect. Proct does a lot of that. They also do quantitative and qualitative research,

so they do a lot of user testing of prototypes, some of which comes back in quantitative form, some of which qualitative form. There's surveys when we're thinking about which feature directions to head in. A lot of that comes back in quantitative form. So that's a lot of it. I guess the

Microsoft stuff for it's like the application telemetry and whatever, we use a good bit of that to keep an eye on exceptions and speed and stuff and that stuff works pretty well and naturally with their hosting. Do you share

any of the data-related stuff with marketing? For example, the data that you collect, the events that you probably collect with segment, is this something that's also redirected to product? Yeah, product and marketing use the same tools. So I think lately mixed panel is what they use to look at user activity.

And they might have different dashboards or whatever, but they're both looking at the same data and the same systems for the most part. Okay, so if I understand correctly, you have marketing, which is doing all the analytics and the dashboards that they need on BigQuery, and then the same events, they are also redirected to Mixpanel, and the product team is using Mixpanel

to do their analysis there. Is this correct? Yeah, marketing also uses some of those same tools to build reports in their own dashboards and whatever. It's only usually when Nick specifically needs to put queries together that are not handled by other systems that he'll go into BigQuery, but he's able to use a lot of the SaaS stuff. Okay.

So it sounds like, and correct me if I'm wrong here, and I hope your product team won't hear that, to be honest, but it sounds like your marketing team is probably a little bit more let's say uh data literate in a way like they're using more tools around the data they are writing like their own sql queries and like you don't see that with the product team right like the product team is going to use a mixed panel and use like a product to do that right uh in terms of like writing queries i would say that's true. And definitely in terms of creating and maintaining infrastructure, that is true. As far as literature and

the uses of data and putting that stuff to work and making decisions based on it, they're both extremely data-focused. Yeah. that's very interesting, actually, because in the industry out there, there's this belief that marketing people, they're not technical people, and it's very interesting to see that in organizations like yours, you see the marketing teams actually being quite competent in taking care of the infrastructure and the data and everything.

And actually, my comment was more about that, to be honest, and not much about data literacy in terms of how they use the data, because, of course, especially in a product like yours, data is very important to drive the product. Yeah, so you're right. They do that, sorry. And it takes a special type of person,

like a multi-class person who's both like marketing and also interested in technology or technology and also interested in marketing we found some of these people within the bank doing like interesting stuff with salesforce and some of their data and like hooking up the marketing systems to each other i think increasingly these types of people are absolutely required um on marketing teams to be able to do this kind of stuff so it all doesn't have to go through it and they're not just like you know dead in the water if they can't figure out how an API key works.

Yeah, I would say, I mean, being the, and please feel free to disagree with me because you are both engineers and I'm the marketing background guy in the room. But I would also say, I mean, from my experience, the infrastructure piece for the product team tends to be easier because you're working within sort of a closed system, right? Like you have the app and the features and the user flows are all defined well ahead of time. And so, and you have, you're working directly with a team that's structuring everything. So it tends to be a much more controlled environment.

Whereas in marketing, you have 10 different tools that all have different data structures. And you have marketing website, landing pages, you're running ads, and you have all this different data to get together, which is just the biggest pain in the world. And it's not a closed system. And you're dealing with all these different things, which I think is, to your point, Sam, actually getting insights from data on the marketing side, just, I mean, I think takes a lot more raw work at the end of the day, because it's way messier. Yeah, that's absolutely the case. The marketplace of companies who want to do something with your data

or collect it or show it to you or aggregate or something is insane in marketing and advertising now. Tough to deal with. Nick has done a great job with that. And it really does just take a specific person or two or whatever like that. That's a role that's not like...

It's increasingly well-defined, but it's not like a traditional one, and it can be hard to find in source. Yeah. Yeah. It's extremely interesting to hear. And I think, again, it's connects to what we said earlier about the rise of all these ops related roles inside the company. I think we are going to see more people like this being around around um yeah as long as like in the bank sorry to interrupt in the bank like for example their it department had like such a you know iron-fisted grip over like all technology throughout the company and they're like worried about shadow it which is what they call like some other departments just signing up for some service

they want that they like they couldn't even have these roles for the most part like because the control was so tight so like every once in a while you get a developer who's interested in marketing like go work in marketing could actually do some stuff with the technology because you knew the people and like the processes and stuff but like organizations that can't let their other departments do what they need to do with their technology infrastructure as far as like and expertise and staffing and whatever. You can't even hardly operate that way. Yeah, I think that's a very good point. Actually, I think there's also a kind of transformation

that is happening, especially with larger companies in terms of their IT and their role inside the IT and even the role of the CIO. I mean, even Gartner who invented in a like, in a way, like, this role. I mean, I think these things are changing. And as we see companies becoming more and more, let's say, technology companies at the end, as some VCs here in the Silicon Valley say,

that, like, everything, every company out there will become, like, a technology company at some point. How good is that to the extent that, like, every company is a money company? Like, it's just becoming one of the things you have to have, one of your systems you have to have to company. Sorry, Colin. Yeah, yeah, yeah, absolutely. I agree with you. But

IT has to be more decentralized at the end to operate. You need to have this kind of people and the freedom inside the marketing team, for example, to, let's's say legalize shadow IT in a way, if that terms makes sense. Cool. That was a great point. So, last question from me, and it has to do more with your experience with using BigQuery.

I know that also Azure has some similar technologies, like the warehouse that they have. And it's one of the technologies that I never had the opportunity to experience. Based on your experience in terms of the data stack and data-related products between the different clouds? What's your opinion? What's your feedback? What do you think about BigQuery? Love it? Hate it?

I haven't used BigQuery much. I like it because it's interoperable with other marketing things. It has a lot of different connectors and a whole little connector marketplace and whatever that was useful to us. I guess the other cloud provider probably has that too now. It was fine, though.

I think the query language is not quite SQL, which is kind of annoying. Azure's is called Azure SQL Data Warehouse, as you might imagine, and I haven't really used it. I don't really know what's up with it. I think it wants to be like a Redshift type of thing. My deepest experience with data stuff is definitely AWS, where I got pretty far into Redshift

and some of its weird constraints and how to optimize it. There's no such thing as a unique key in it, for example, and what kind of queries will go fast versus slow, so how the architecture influences that. And then started getting more into data virtualization, which is using stuff maybe more like Spark and Athena on AWS,

which can take a bunch of JSON files and overlay a schema on them, and also include some SQL data in that schema, and then a different JSON schema also, so you can query all of that together, so the data's virtualized, and you can query multiple sources at once, and do it in a way with Spark

that is extremely computationally scalable, and you gotta back that with some crazy systems, some crazy highly available file systems and stuff. This is to say that even though Google started with the like Hadoop stuff or whatever, I'm sure they're still moving that forward. It seemed to me like AWS was the most advanced in like the really insane stuff that people are doing with data these days.

But I haven't checked the other providers that closely either. Yeah. Do you use any of these technologies inside Ruby right now? No, not anymore. When I worked at that consultancy, we had some Hadoop work, trying to rescue this really god-awful implementation. Did some data virtualization and stuff called entity resolution and record linkage

on AWS with some pretty advanced tooling. But we don't use any of that stuff in Ruby now. That's interesting. So, last question. You mentioned that you're probably going to become like a spin-off and start operating outside

the bank. So, based on that, what's like the biggest change that you anticipate to see in your work, like the technical side of the company? And if you think that this change is also going to affect your stack, your technologies, and whatever, what excites you about that?

So the biggest change will probably be something as mundane as operating our own email, like as far as technology goes. Like they did it before, now we'll do it, like whatever. It's G Suite, it's email, it's fine. We've honestly become pretty decoupled from the bank's requirements after kind of learning what they require of us and like how to do that stuff and get around it or not and like go through their processes for review probably the thing i'm most excited about is not having to do their like production readiness assessment you know product assessment stuff before we roll out which is like that process is built for everything from like you know a new email subsystem to opening 100 new branches like it asks if we have all our signage correct. It's crazy. So not having

to deal with that would be fantastic. Sounds great. So thank you, Sham. It was great to actually have both you and Nick because it was an amazing opportunity to get the different

stories of the same thing at the end, at least for me and i guess also for our listeners it's going to be great to see how things can work inside the company and how like marketing and engineering complement each other and to deliver like at the end this great experience thank you so much cool thank you guys yeah it's a great experience. Thank you so much. Cool. Thank you, guys. Yeah, it's a pleasure. So I think that was great. I mean, it was quite surprising, first of all, to listen to a startup that is actually building their whole product on Azure.

So that was also, for me, a very rare opportunity to learn more about how much Azure has progressed in the past few years from being a quite immature product at the beginning becoming something that can easily compete with AWS and Google at this point. Also, I found very interesting the coexistence of marketing with engineering. I think the kind of boundaries that Sam was mentioning

are very interesting and important to exist in every company. Overall, I would say that was an amazing and very surprising discussion to have, and I really enjoyed it. What do you think, Eric? Yeah, I mean, it's so easy to hate on microsoft and i mean there are just lots of microsoft jokes out there um you know it's it's kind of shocking to hear someone say like yeah we we are a microsoft shop and it all works really well um it's just kind of surprising because you're just thinking about all the memes

that you've seen about Microsoft. So that was really interesting. And I just appreciated how Sam, he comes from an AWS background. And so you can tell, like many engineers, he wants the tools that work best. And he was very transparent about how well AWS worked. I think the other thing that really stuck out to me was just, this may sound funny, but how little Sam had to say about involvement in the marketing infrastructure.

You know, I think that really, in many many ways it has allowed Sam to really focus on the core product functions as a CTO, um, which I believe has really probably helped Ruby move faster. Uh, so that was funny. I mean, we, we ended up spending way more time talking about Microsoft than we did marketing, but, um, you know, he basically said marketing is doing a great job and they built a bunch of infrastructure and we check the security stuff to make sure it's okay, but they're off to the races. Uh, so that was really cool. So I really appreciated the, uh, the conversation with him.

Yeah, absolutely. I mean, it's, uh, very refreshing and very nice to hear, uh, like to see like this kind of healthy coexistence between marketing and engineering in a company. And I think they've managed to do it very well. And now that they're going to spin off, I think we will have the opportunity in the future to chat again with Sam and Nick and see how things changed through this quite huge transition

that the company is going. Absolutely. Well, until next time, thanks for joining us on the Data Sack Show. This is Eric Dodds and Costas Pardalis. See you next time.