Ep. 172 Skyflow: Data Privacy & Security

Sean Falconer: I wanted to live in a world where everyone recognizes that something like a data privacy vault is one of the foundational pieces of any architecture, just like you would have an application database, a data warehouse, and so forth. I would love it if you're using Skyflow to do that, but even if you're not, this is something that just makes too much sense from a PII management standpoint, just like you use a Secrets Vault for managing your API keys and passwords, you shouldn't be using essentially these pre- existing tools to try to manage something as complex as PII. Hey, everyone, this is Sean Falconer, head of Marketing and Developer Relations at Skyflow, and this is the MongoDB podcast.

Michael Lynn: Welcome to the show. My name is Michael Lynn and this is the MongoDB Podcast. Today we've got another exciting episode where we delve into the world of data privacy and security with our special guest Sean Falconer from Skyflow. In today's episode, Sean draws from his wealth of experience as a successful technologist and founder to take us on a journey through building a data privacy vault. He explains the importance of protecting sensitive data and how Skyflow's polymorphic encryption, and tokenization technologies ensure that data stays secure. You're going to discover how Skyflow tackles the challenges of data privacy in this age of generative AI and how they're helping businesses protect corporate secrets and customer information alike. Join us as we explore the cutting- edge world of data privacy and learn from Sean's experience in developer relations and marketing where authenticity and building genuine relationships are key. Stay tuned. I hope you enjoyed this episode. Sean, welcome to the show. It's great to have you on the podcast. How you doing today?

Sean Falconer: I'm doing great. Thanks so much for having me, Mike.

Michael Lynn: Fantastic. And where in the world are you?

Sean Falconer: I live in the San Francisco Bay Area, although I've been on the road for the last four weeks and I actually am leaving tonight on a flight. So the last month or so, it's hard to tell where exactly, what time zone I'm in and where I'm living.

Michael Lynn: I know the drill. Traveling can definitely be a challenge. I understand you were recently speaking at a conference. What was that about?

Sean Falconer: Yeah, so I was at the Infobip Shift conference, which is their first time doing a US- based conference. Infobip is a fairly large company that's based out of Croatia and they actually run one of the largest developer conferences in Eastern Europe in the world. Then this was their first foray into the US, so it was about a 500 person conference or so in Miami focused on developers. I was an invited speaker, so I went there and gave a talk titled What If Privacy Had an API, which was all about the challenges around why hasn't there been an API built as an abstraction layer to something as complex as data privacy, and dipping a little bit into some of the work that we've done at Skyflow.

Michael Lynn: That's exciting, and we're going to dive deeper into that space for sure. I wanted to get a sense of your background. I was checking out your LinkedIn and you've got quite an impressive academic background. Talk a little bit about your path in academia.

Sean Falconer: Yeah, I've done a lot of different things. I sort of started my career somewhat as a software engineer or on that path and I worked as a software engineer all through school, but I actually ended up doing three different degrees in computer science over about a 10- year period. So I spent pretty much my entire twenties in university in some capacity. Originally, I'd wanted to be a professor or an academic of some sort, and eventually after finishing my PhD, I went on to do a postdoc in bioinformatics at Stanford University, and that's what moved me from Canada to the US. That was always a dream of mine to do research or be part of the academic scene at one of these hallmarks of academia, like a Stanford University or MIT or something like that. When I finally had achieved that, in a lot of ways it was... Even though there was some great things about it and I got to work with some of the best people in the world in the research community, I also started to recognize that maybe this was not the path that I ultimately wanted to do. And partway through my postdoc, I actually ended up starting a company with two other students at Stanford, and later that year we had raised our initial seed round for the company and then I left academics and Stanford after a year to go and build that company full time.

Michael Lynn: That was Proven, right?

Sean Falconer: Yes, that was a company called Proven.

Michael Lynn: Yeah, and what was the business model for Proven?

Sean Falconer: Oh, we went through a lot of iterations and we did pretty much everything wrong that you can do wrong as a startup founder, but I learned a ton. But ultimately what we ended up being in terms of business model was... Let me back up a little bit. So what we were originally set up to do was try to democratize the way that blue collar work or sort of hourly wage work works, labor functions in the United States. There's lots and lots of technology tools built for both the people doing the hiring as well as those who are seeking employment in sort of white collar, traditional university educated people. There's a lot less available for people who are working in the service industry or working maybe as a carpenter or a plumber. And we wanted to be able to modernize that industry, applying technology, applying approaches like mobile. Originally it was like text messaging and so forth, and that eventually we came into smartphones as that started to become a bigger thing in a bigger way that people interacted with the world. But we wanted to be able to transform that industry. Eventually we pivoted into something that was essentially a lightweight applicant tracking system for restaurants and hospitality, service industry, trying to hire hourly wage workers and then on the other side of the marketplace providing tooling for the people trying to find those jobs to be able to apply for those jobs really easily, represent themselves well online, make sure that they show up for the interviews and are able to be set up for success. Essentially employers would pay us to post and host their jobs and syndicate that out to a variety of different job boards.

Michael Lynn: Great business model. Then of course that was acquired.

Sean Falconer: Yes, it was eventually acquired after eight years by a company called Upward, which has now subsequently been acquired by another company.

Michael Lynn: What great experience though, so from academics into a starter founder role and now in the security and privacy space. What's happening at Skyflow and what's your role at Skyflow?

Sean Falconer: I was originally brought on at Skyflow to be the head of developer relations, so that was a role. Prior to Skyflow and after my startup, I ended up joining Google and there I led developer relations and developer experience teams for four different API products, not in the data privacy security space at all, but more in the actual business communication space. But Skyflow was a company that I was really, really interested in. The CEO and founder of the company had been an investor in the company that I started., So we had known each other for a number of years and I was really impressed by the leadership team and the vision of the company. Ultimately what Skyflow is is it's a data privacy vault for customer PII. I think a good analogy for this is if you think about your own finances, say you have gold and jewelry and the money that you make from your job, typically we do not choose to store our finances within our house because essentially if we were stuffing our money under our mattress and keeping gold wherever in our house, then what would end up happening is we're taking on the responsibility of protecting it, and most of us don't have the resources, the expertise to protect that, and we'd make ourselves a big target. Instead, what we do is we rely on putting that stuff within a bank where these financial institutions are set up with the resources, the staffing, the know- how, the security to protect it, and they also have really sophisticated vaults where all this stuff lives and makes it very, very hard for anybody to get access to it. Instead of using the money directly, we usually use a proxy to that information in terms of a credit card or a debit card. Then if the credit card gets compromised in some way, well, we cancel the credit card, but the actual money that's being stored within the vault within the financial institution is not necessarily impacted by that. In the same way, Skyflow is essentially a data privacy vault for customer PII. So instead of thinking about your financial resources, which are perhaps your most precious resource besides your family or something like that, the most precious resource for many businesses is their customer data and they want to make sure that it's really well protected. So they essentially move their customer data into these data privacy vault architectures, which are specially designed for essentially allowing you to isolate, protect, govern, and use that data outside of your existing application infrastructure.

Michael Lynn: Talk a little bit about what's happening at Skyflow and what your role is.

Sean Falconer: Yeah, absolutely. Just to back up slightly, after I was done with my company, essentially, I went and I moved to Google, so I worked at Google for a number of years. There I moved essentially from being at my original company at Proven, I was the CTO and co- founder of the company. Even though I was the technical co- founder of the company, because we were not ever like a rocket ship that had thousands of employees or anything like that, I had to learn how to do a lot of things that were initially outside of the scope of probably my core expertise, which was more on the technology side, so I learned a lot about business, marketing, sales and so forth. When I joined Google, I actually joined in the developer experience and developer relations side of Google, so still engineering, but with a little bit more of a educational, marketing lens to it. I was leading developer relations and developer experience for four different API products there, and not in the privacy and security space, but actually in the business communication space. But I was really essentially engaged and interested in joining Skyflow because of the vision of the company, the leadership team, the CEO and co- founder Anshu Sharma was actually an investor in the company, Proven, that I had started years ago. We had known each other for a long time and when he approached me about the idea of joining was, initially I was very, very intrigued and what they're setting out to be is essentially develop, or our tagline is" What if privacy had an API?" So it's this idea of, " Can we create essentially an abstraction layer for something as complicated as data privacy?" The way that we do that is we are a data privacy vault for customer PII, and I think a good way to think about that is if you think about your own, the money that you earn at your job, or if you had gold or diamonds or something like that, then typically you would not store the money that you earn at your job in your house because if you're stuffing that under your mattress, then essentially you're taking on the responsibility of protecting it. Most of us don't have the resources, the knowledge, the core competency to put the right safeguards in place to actually protect it. And on top of that, we'd be making ourselves a big target to potential threats now. What we end up doing is we typically store that money with a bank and then the bank has the resources, the knowledge and so forth to protect it. On top of that, they have very sophisticated vaults where they put all that money and financial resources, and then you use proxies for the value that you have in the bank in the forms of credit cards or debit cards to essentially access that information. If the credit card gets compromised in some way, then, well, you just cancel the card, but the actual financial resources that you're storing within the vault are actually not impacted in some way. essentially we are doing something similar, but for customer PII, so we provide this core concept of a data privacy vault, which you can think of it as essentially a way of treating customer data, something special outside of your existing system, and it's set up to isolate, protect, govern, and give you ways of actually managing and using your PII. In the same way that the money that we have might be one of the most valuable assets that we have in our lives, besides our family, customer data is one of the most valuable assets that a company has, and they want to make sure that not only are they meeting whatever the privacy regulations say that they need to be able to do, but they also want to make sure that it's not compromised in any way, so they can leverage essentially this technology to do that.

Michael Lynn: I want to start by looking at a definition of PII. There are developers putting applications together, they're storing customer data. What is sensitive? What is PII?

Sean Falconer: Yeah, so that is probably a more complicated question than you even maybe intended. PII stands for personally identifiable information, and it actually the definition, the legal definition of PII, and I will preface by saying I am not a privacy lawyer, so take this with a grain of salt, an engineer that knows something about privacy and security. But the definition can vary depending on essentially the type of regulation that you're looking at. But the way I think about it, and I think this is the most sort of applicable for anybody in engineering spaces or any company founder, is to think about not just PII but essentially sensitive customer data. What is sensitive customer data? This is data about your customers that you wouldn't want showing up on the front page of The New York Times because you had a data breach, essentially. Anything that is at that level of sensitivity that you wouldn't want exposed in some capacity because it would be embarrassing for your company and bad for your customers, then you want to essentially treat that as something different than regular application data and have a lot more safeguards and security in place. Ideally you're leveraging a technology like a data privacy vault to do that.

Michael Lynn: That's pretty wide- reaching. It could be everything from customer names and addresses and purchase information. You would probably draw the line at product information that is yours, bespoke information, right?

Sean Falconer: Yes. I think of it more as information that relates to the customer directly or would allow you to identify the individual if you had enough access to that information, but not essentially your application data, analytics data, clicks on a webpage, stuff about the products that if you were some sort of retail company or you sold some sort of product, you wouldn't store your product information within a data privacy vault. But you would store information about your customers, account information, their credit card information. If you were doing things like identity, then you might need to keep track of their Social Security numbers so that you can run things like KYC or their driver's license, picture of their driver's license or something like that. That is essentially customer data that you would want to protect.

Michael Lynn: How does it surface to the developer? Let's say I'm developing an app and I'm typically familiar with how to establish a connection to a database and I begin accepting data from a form, maybe it's a web form or a mobile form, and I store that in my database. But if it's PII, I want to take a different approach and be more secure about it. How does that surface to the developer with Skyflow?

Sean Falconer: Yeah, so that's a great question. I mean, there's a few different ways that you could do this, depending on how complex your infrastructure is and also what your needs are, and the type of information that you're storing. But the ideal scenario is whenever you're dealing with sensitive customer data is that you're going to de- identify it as early in the life cycle as possible and then re- identify it as late in the cycle as possible. So if you had a form where you're collecting information about a user, and this is their name, their email address, their home address, or like their phone number or something like that, then ideally from your front end application where you're collecting that, instead of sending that through an API gateway and then other downstream services eventually ending up in your database, you would leverage Skyflow's frontend SDKs to send that data directly to your data privacy vault. Then what would happen is the vault would return essentially a reference in the form of a token back to your application front end. You can think of this like a pointer essentially. It's a stand- in for the original value, but it's de- identified information, so there's no mathematical connection between the input value, say someone's name, and the resulting token. So even if someone gets the token, they can't reverse engineer it back to the original value, but you can use it essentially as this reference. Then you would pass the references downstream through your API gateway and your other downstream services. So those references would end up in your database and your data warehouse and anywhere else where you're storing it or potentially your log files or however else you're storing that information. But that ends up effectively de- scoping all of your application infrastructure from touching any of this customer data. Then the only time that you would re- identify it is let's say someone logs into the application, they go to their account page and they want to be able to see their account information. Well, it's probably going to surface their name, it's probably going to surface other... maybe their phone number or something like that, whatever other information they signed up with. Well, in that case, your application is still going to function exactly as it would if you were handling the raw data, but in this case you're handling tokens, so the tokens end up getting passed back to your front end and then your front end would essentially make a frontend SDK call to exchange the token for the original values allowing you to resurface those, so you're them as late in the lifecycle as possible, in this case at render time.

Michael Lynn: I imagine using some form of TLS or you're encrypting the pathway as you're sending that data back and forth, right?

Sean Falconer: Yeah, absolutely. Anytime you're talking about privacy and security, of course, you want encrypted at rest, encrypted during transit. We actually, in our data privacy vault, we pioneer a technology known as polymorphic encryption, which also allows you to run fully encrypted operations as well. So you can run a variety of different... essentially like SQL statements directly against the vault, against fully encrypted data. Then there's other of course features of the vault that allow you to run compute even within the vault. So you could run custom code that runs within the secure environment of the vault and allow you to perform some sort of algorithmic operation against the PII without essentially exposing your systems to the plain text values.

Michael Lynn: Now, I know you didn't build this, so I may be throwing your curve ball, but what does the stack look like and how was Skyflow built?

Sean Falconer: Yeah, so I can go into a bit of detail there. It took about two years to build the initial vault. The company was formed in 2019, so we're about four years old, and the first two years was really just R& D, so most of the company was engineering a product. We really have only had sort of go to market for the last 18 months or so. The reason for that is it's not a move fast, break things type of product when you're talking about data privacy and security, and it's a big lift to build essentially these architectures properly. So if you look at companies that have done something similar, so there's been a handful of companies like Google, Netflix, Apple, Shopify, and Capital One and so forth that have built similar architectures and ideas to the data privacy vault. But Shopify, it took them about three years and almost 100 engineers to build their version of a vault, and that was just for analytics. Essentially we took some inspiration from these different companies and tried to build that for everybody else and abstracted away in the form of STKs and APIs. But where we began of course is with the secure data storage or secure data layer, so how do you actually store this data and protect it? We had to develop a number of different technologies to do that, including the polymorphic encryption approach that I spoke about, as well as different forms of tokenization. A lot of people, a lot of developers might be for somewhat familiar with something called PCI tokenization, which is if you've ever used a payment service provider like a Stripe or Braintree or something like that, then in that case you're never handling credit card data directly. Essentially you're using their SDKs to embed some sort of form which actually runs on Stripe's infrastructure. So it essentially removes your front end from PCI scope and the credit card data goes directly to Stripe and then Stripe returns some sort of token representation which you then use and save within your application. Essentially that is a simple form of tokenization where you're essentially getting some sort of random string representation of that original data and you could do all that kind of stuff with Skyflow as well. But we had to do that at a much more sophisticated level in order to support a variety of different workflows. Not only can you create sort of random tokenization that you can use as representation for the original data, but you can create things like format preserving tokens. So an email could still look like an email or a phone number could still look like a phone number. That way if anything in your downstream services expects things to be formatted in a certain way, you could still give it tokens that look the same but are not the original values. We generated things like deterministic tokens, so these are essentially tokens where the same input will always produce the same output. So Sean Falconer generates the same UUID every time the vault sees Sean Falconer, and that allows you to then run analytical operations in your warehouse against the tokenized data because the warehouse doesn't need to see Sean Falconer, it just needs to see essentially the same type of string every time so that it can perform joins and counts and group buys and so forth. A lot of that technology was a sort of initial layer, and then on top of that, we had to build essentially a governance layer, auditing, authentication, authorization layers, and then build in different deployment models for different infrastructure deployments depending on what a customer needs, like single tenant, multi- tenant and so forth. Then build these workflow layers on top of that, which is something that was a fairly recent development in the last year, which is how do you perform essentially operations on data within the vault like algorithmic operations or pipeline ingestions and ingress, egress in and outside of the vault, and then finally layer on an API and SDK that abstracts all that stuff away so that as an application developer, I don't need to know how to build all that stuff or even need to know all the ins and outs of it. All I need to know is, " Okay, well here's my REST API interface to send data into the vault and get the data back out.

Michael Lynn: Even to this day, I run into customers who describe for me a scenario where they just can't have data off premise. They need to have everything encapsulated. Is there a solution in the Skyflow portfolio for that?

Sean Falconer: You're talking about on- prem versus cloud?

Michael Lynn: On- prem, yeah. Mm- hmm.

Sean Falconer: We don't provide an on- prem solution today, although if you were storing data on- prem, of course, and you are comfortable with the idea of having some of that data exist in the cloud, there's nothing stopping you from having that data go into your Skyflow vault. But essentially we were born in the cloud, we are a cloud- based solution. But of course the way the deployment works is we essentially separate things from a control plane and data plane. The data plane is where only you have access, so it's your data. We essentially just manage the services on top of it, so we don't have access to the data. We're just managing those services on your behalf and then you have complete control of the data through a secure link.

Michael Lynn: Customers that are concerned about security and privacy, they naturally scrutinize any partner they're going to get into business with. As a relatively new company, how do you overcome that issue of trust?

Sean Falconer: Yeah, that's a great question, and I think that is something that any startup that's trying to sell into bigger businesses, of course, is going to struggle with. Now there are certain benchmarks that you have to hit as any business that's working in security and privacy. So we're PCI Level 1 compliant, SOC 2, ISO 20001, and we've gone through all those various security audits. We also have done the AWS FTR review, which is required for their marketplace, where essentially AWS has their solution architects go through everything that you're doing from a infrastructure standpoint to make sure that you're meeting the best practices from a security perspective. So we've had all those third parties of course look at our systems and make sure that we're doing the right things that you'd be expecting of any business that's working with this kind of data. Some of those, of course, are required to even handle the things like patient data or credit card information. Now, there's of course other things that help as well when you're looking at our company is essentially the leadership team is a big factor. Anshu was a former VP at Salesforce for a long time, and before that he worked at Oracle and has been a successful investor. So he's a known entity that's also well- connected and really understands SaaS and enterprise software. Then our chief product officer is also a former VP at Salesforce. So we have essentially, from a pedigree standpoint, people who have had leadership roles at data companies, security companies and so forth. Our head of security and compliance also has over 50 patents in database encryption and security, so he's invented a lot of the modern techniques that are used to protect data today. He did that, a lot of that work, 20 years ago and has the patents on those. So we have from essentially a thought leadership team depth and expertise, a lot of people that can essentially speak to what we're doing from a security perspective.

Michael Lynn: You talked about this evolution and it started with the vault, extended to an API. What's late breaking and what's in the future for Skyflow?

Sean Falconer: Yeah, so of course most of the world, GPT's always on everybody's mind these days, so we recently launched a new product line called Skyflow GPT Privacy Vault. It's essentially our vault offering for helping protect the insecure GPT workflows. A lot of companies of course are very excited about everything that's going on in generative AI, GPT, but there's also a lot of security and privacy concerns as well as people start to think about building their own generative AI systems. One of the hard things about GPT- like systems is they're really designed for learning and remembering. They're not designed for forgetting. So once essentially sensitive data ends up in a GPT model, it's kind of there forever. There's no easy way to delete it. It's not like going and deleting a row from a database. It's sort of no way to unlearn something within a GPT model. So how do you solve that problem? Essentially the best way to solve that problem today is to make sure that the information doesn't end up there in the first place. So with Skyflow, you can essentially protect all parts of essentially building a generative, a GPT- like system from training to inference to prompts. Essentially we sit in between wherever that, say, your training data and your GPT model, Skyflow can sit in between there, essentially the information, the training data can go into Skyflow. We will identify where the sensitive information exists, replace it essentially with de- identify data or fully redacted, whatever you need, and then give you clean data on the other end that you can do your model training with. It's similar from a prompt standpoint. Someone essentially can take an internal document at a company, like I believe happened at Samsung, copy it, throw it at GPT, and now GPT essentially has access to it. But Skyflow again, could sit between essentially the prompt and the GPT, filtering out the sensitive data, replacing it with essentially deterministic tokens so that you can actually have referential integrity so that when the GPT response comes back, you could replace those tokens with the private information. This allows you to not only protect PII, but also protect essentially corporate secrets. Lots of companies have internal names for product lines that are in the works that they don't want leaked. Well, how do you protect that? Essentially this is a way to do that.

Michael Lynn: Not something I've thought a lot about, but so there's protecting the use of and improving the use of LLMs and ChatGPT. There's leveraging the technology. Is Skyflow using AI in any way?

Sean Falconer: Yes, for things like PII detection, there's elements of AI there as well. We're not currently using LLMs directly within the vault, although of course that's such an evolving fast- moving space. Those are things that we're looking into. We're also leveraging GPT- type systems within Skyflow as essentially a way to enhance our efficiency as a company, so there's some interesting things going on there. One of my colleagues, Manny Silva, our head of documentation who I also worked with at Google, has built a bunch of internal applications that leverage sort of our own internal versions of GPT that we can train on corporate information, corporate documents, and then we can go essentially from something like a PRD to generating a lot of things like documentation, read me files, a blog post, PR release, and so forth. Of course that's not the end result. You got to do a lot of editing on that, but for most people it's easier to do editing than it is to essentially create something from a blank page.

Michael Lynn: Yeah, for sure. We talked a little bit about AI and that's kind of in the roadmap space, but are there key developments coming from Skyflow? What's on the roadmap?

Sean Falconer: Yeah, so besides some of the work that we're doing around GPT, we're doing more of course around being able to detect PII. Essentially we want to be able to support the full workflow that somebody might be doing over sensitive data. We do a lot of work with a variety of different partners, companies like AWS of course, and Snowflake and Beyond, so we're continuing to build integrations into those different platforms so that we can support whatever types of workflows you want to do there without essentially compromising any privacy and security. We're also continuing to enhance some of the things that I mentioned around being able to run and execute your own code code within the vault. There's always things around performance and scalability you need to be addressing, and those are big areas of investment as well.

Michael Lynn: We're both in developer relations, both in marketing. I'm curious about your approach to marketing to developers. It's a tricky space and developers don't typically like to feel like they're being marketed to. What's your approach to that?

Sean Falconer: Yeah, so people always talk about how developers don't like marketing or they don't being marketed to, but I honestly think that developers don't like bad marketing, and that's true of all humans. All humans don't like bad marketing. There's plenty of marketing campaigns. I think the Twilio, one of the Asher developers, one of the most famous ones that is a really well- executed marketing campaign that I think developers for the most part probably really liked. I think a lot of it comes down to authenticity, speaking the right language and understanding your audience, and that's true probably of any type of marketing. For me, I think I always, from a marketing developer relations standpoint, I think the core of developer relations is really about building relationships. That's why it's in there as such an important phrase within there, and sometimes we forget a little bit about that. But it's like how do you build authentic relationships with people? I think if you're focusing on that, you're going to be successful, either as an organization or as an individual contributor. It's like how do you essentially connect with people? How do I find people that are interested in this thing, have certain types of problems that I'm interested in helping solve or they're interested in solving and then connect with them in an authentic way. Then additionally, it's also about building relationships internally within the company and then building trust with your product and engineering counterparts, your other marketing counterparts, your sales leaders and so forth, and figuring out, " How can I take essentially my knowledge as well as the knowledge of what's going on in the community, the asks that are happening, the types of things that developers want, and give that as a feedback cycle to help improve our product, to help improve our sales cycle?" That's also all about relationship building and building that trust there. You have such an important place in a business if you do it right, where you're this cog essentially between those external developers and the internal teams, and you can be this conduit of information that's going back and forth. That really just comes down to how do you build trust on both sides of that place, and that's really the foundation, I think.

Michael Lynn: Yeah, I like that. I mean, I think it begins with good product that developed with the developer in mind, and it sounds like you've done that at Skyflow. You've got the API, you're thinking about how developers are going to access this and leverage it to get the best use, and that sounds like a really positive step. Then you're doing things like this podcast, but what else is in the tool belt at developer relations at Skyflow?

Sean Falconer: Yeah, so we do a fair number of things. One of our big challenges, I think as an organization, one of the reasons I was really excited to join, is we are a new category of product. Most people don't know what a data privacy vault is. I imagine it's kind of similar to the early days of MongoDB when people didn't know what a document store is, and it's like, " How do you essentially go and create momentum and market knowledge around this concept so that people actually know the benefits of it and why they would want to use it?" So a lot of my first year at Skyflow was focused on how do I get to the tallest mountaintop and shout from the top of that mountain like, " Hey, data privacy vault is a thing you should know about." It wasn't necessarily like, "Skyflow, Skyflow, Skyflow, it was just this core concept. This is something that you should know about." I wrote an article early in my time at Skyflow that I had published at Software Engineering Daily called why every engineer should know what a data privacy vault is. Then I think I wrote that in the second month I was at Skyflow, and it was published probably in the third month. Then fast- forward six months later, this IEEE article came out about the future of privacy engineering written by some leadership team at Infosys. In that they talk about how we're shifting from privacy by design to privacy by engineering, and essentially the best practices around privacy by engineering is to leverage this technology of a data privacy vault. The reference they used for that article was the article I wrote, which is like, that is developer relations sort of full circle. If you look at our announcement for Skyflow GPT Privacy Vault, the author of the IEEE article from Infosys is actually the person who's quoted in that press release. It's so hard, I think, when you're in developer relations, a lot of times there's a lot of this pressure on like, " How do you show value, the business value, why are you here, why are we paying you and so forth?" But that is why you're getting paid is essentially can you do something that really speaks to people that is done in an authentic way, you're trying to teach them something, and then essentially you continue to invest in those types of things and you're going to see that value that comes out at the other end. So I do a lot of writing, I do a lot of speaking as well as other people on the team to just get the word out about this course concept. I really firmly believe that in the next five to 10 years, I want to live in a world where everyone recognizes that something like a data privacy vault is one of the foundational pieces of any architecture, just like you would have an application database, a data warehouse and so forth. I would love it if you're using Skyflow to do that, but even if you're not, this is something that just makes too much sense from a PII management standpoint. Just like you use a Secrets Vault for managing your API keys and passwords, you shouldn't be using essentially these preexisting tools to try to manage something as complex as PII.

Michael Lynn: So downstream, your company's going to do better because of your efforts, but how do you measure?

Sean Falconer: Yeah, so I spent a lot of time in my days at Google on measurement. When you're at a big company, a big organization like that, so much, especially in a leadership position, a lot of your time is spent on, " How do I create visibility for my team? How do I justify our existence? How do I justify headcount and so forth." So it's a lot of essentially internal developer evangelism to some extent. You're going around and making sure that people understand what you're doing. At Skyflow, there was things that in the early days I really focused on metrics, but I think in a lot of ways, not that metrics aren't important, but in a company where you're 100 people, series B, there's nowhere to hide within an organization that size. So in a lot of ways you can get distracted by trying to spend too much time justifying your existence on metrics versus just doing good work. Because if you do good work, people are going to know already because there's just nowhere to hide. I think everybody understands the impact that you're having. And of course things like the IEEE article that's directly attributed back to me is impactful from a business standpoint. But I think a lot of times the best things that you can do is, again, focusing on building those core relationships, making people understand your value and opportunistically looking for ways to help people. If you create a demo that you did because you were interested in it, you wanted to open source it, you want to do a talk, well, that asset could also be a great sales enablement tool. You don't want to essentially stop at the part of putting it on GitHub, but follow that story through and figure out, " How can I have more impact in the business beyond just my individual contributions?" I think that is the key, not only to success and develop relations, but also to upleveling in your career, whatever your function is, thinking about, " How do I scale beyond myself and looking for those opportunities to do that?"

Michael Lynn: I love that. My leadership team, Peder Ulander and Matt Asay, and even up to Dave, it's been a message of, " Find ways to get deeper impact." We can all have an impact on a wide number of areas, but we're really focusing on, especially in this economic climate, ways that we can have a much deeper impact on our core constituents, or the developers, how can we really improve their lives? So what's your approach to that wide versus deep approach?

Sean Falconer: Yes, that's always a tricky thing I think, and especially like a startup. It's very easy to be doing a million things. Most startups, and I've learned this as a founder myself and I made lots of mistakes with this, it's like you die of indigestion, you don't die of lack of good ideas essentially. So it's really comes down to, " Which of these thousands ideas do I... What are the five that I should actually focus on?" I think a lot of that comes down to... I use an OKR planning model. I like to go by quarters. I think in a startup you might even be able to go shorter than that because things are moving so quickly. But one of the things I try to have our entire team do is... Actually at Google, when you do OKR planning, you're looking at, " This is everything that we're going to do. This is everything we're promising. And if we hit 70%, well that was good." No one's expected to hit 100%. But I think at a startup, in my experience anyway, you don't want to be that prescriptive because there's too much new information all the time. So what I try to have the team do is look at, " What are the big rocks that are most impactful that I need to focus on for the next three months," while leaving enough space for essentially new information as well as opportunistic things that could come up that you can try. Then always going back after this three month cycle and looking back at essentially running a retrospective of how impactful was this? " Was this value add or what would I change?" Essentially always asking yourself of" What went well, what didn't go well, how can I improve?" And then using that feedback cycle, and it's all about essentially speeding up the flywheel of learning. The faster you can have that flywheel of learning going, then the faster your learning cycles are and essentially the more likely you are to be successful. I think a lot of times success is not necessarily about being so much better than other people, or from a competitive standpoint. It's about survival, essentially. Can you survive long enough to find the thing that actually is going to work? You see that all the time with startups where they're quote, unquote" overnight success" but no one saw the eight years that they were crawling on their belly through the gutters to get there and all the hard work that went into it. The only reason it feels like an overnight success is because no one cared until they were actually successful.

Michael Lynn: I get that. Well, this has been a great conversation, Sean. I want to thank you for spending time with us. What else do folks need to know about Skyflow before we break?

Sean Falconer: If you want to learn more, definitely check us out at skyflow.com. I also host a podcast called Partially Redacted at skyflow.com/ podcast, and you can also find that on your favorite podcast catcher. But that podcast, it's not about Skyflow, but it's about the privacy and security space, so we cover a lot of security, privacy, engineering related topics. So if that's something interesting to you, you should definitely check it out. I also am one of the co- hosts of Software Engineering Daily, which you can find at softwareengineeringdaily. com, which we essentially do deep dives into the various engineering topics with engineering leaders within the industry.

Michael Lynn: Great. I'll include links in the show notes to Skyflow and all of the things that we mentioned during the podcast. Sean, thanks again.

Sean Falconer: Thank you so much for having me.

Michael Lynn: Thanks so much for joining us today for this insightful episode. Thanks to Sean for joining us today, and thanks to you, the listeners. Remember to check the show notes for links to Skyflow's website, the Partially Redacted podcast. Remember to check the show notes for links to Skyflow's website and other resources we discussed today. If you enjoyed this episode, don't forget to subscribe to the MongoDB podcast. Leave us a review and share it with your friends and colleagues. Thanks again for tuning in. Until next time, stay curious.