Episode 89: SingleStore's Jordan Tigani on Data-Driven Decisions

Brian Dawson: Hello. Thank you for joining us for another episode of DevOps Radio. I'm Brian Dawson and I'll be your host. Today with me we have Jordan Tigani, the Chief Product Officer of SingleStore. Hello, Jordan. How are you doing?

Jordan Tigani: Hi. Great. Thanks for having me.

Brian Dawson: Yeah, I'm glad to have you. And we were talking a bit before we started hitting record and I'm kind of excited about carrying that discussion forward and some of the topics that we may cover with our audience here to listen.

I will want to learn a bit more about SingleStore, so I have some questions queued up, but before we do, to start can you give our listeners an overview of your role at SingleStore? What do you do today and what's your career background? How'd you end up where you're at?

Jordan Tigani: Sure. Thanks. So, I'm the Chief Product Officer, and so I'm in charge of the engineering and product teams, and so to me that is sort of – it's ideal because I get to sort of wear both hats of my last two jobs. My last job was I was running product management for Google BigQuery and before then I was running engineering for Google BigQuery, and so this sort of lets me kind of play both roles. I started out as an engineer. I worked at Microsoft as a Windows kernel for a while, I worked in Microsoft research, I worked at a couple of startups, really caught the startup bug

But then I caught the Google bug, and Google was a really exciting place that felt like a startup to me. It felt like there was very little bureaucracy, very little red tape. People were moving quickly. Engineers with an idea could get things done. I was starting in one of their kind of internal big data, data management systems, and kind of got pulled into this newfangled product that was just being spun up that then became BigQuery. So there was about a half dozen of us, which was a huge team at Google at the time.

Brian Dawson: Wow. [Laughs]

Jordan Tigani: Everybody would compare it to Gmail, which was like five people that created Gmail, so it was like, well, if Gmail would've only been five people you guys should be able to do this one faster.

Brian Dawson: Do it with six.  You guys are swimming in resources, right. [Laughs]

Jordan Tigani: And then starting from what are we going to build, and we had some internal-grade database technology, data analytics technology, it was called Dremel, building a SaaS service on top of it. I built the storage system. I ended up running the storage team and then ended up as engineering director and then PM director, and it was just a great and exciting to go from zero to where BigQuery is now where I guess they don't like to talk about revenue numbers but it's doing quite well in the market.

Brian Dawson: Good. I was going to ask specifically about that. Now I assume – so first, it's interesting because I kind of secretly love data, I secretly want to be a data scientist. 

For my son's sports team I'm the spreadsheet guy and I build out all of these analytics that nobody looks at. You know, they're vanity analytics. So when I stumbled across BigQuery it immediately caught my attention, a reasonably full-featured, flexible SaaS not only database but it was more the interface layer and the ability to go in and derive insights from it. That nature of where I stumbled across it, and there may have been a bigger launch than that launch, but can you tell me, is it similar to Kubernetes? Was BigQuery first started and/or built on internal needs and then created as a product or did you start it as a product?

Jordan Tigani: There was an internal product called Dremel, which was an internal tool that somebody built while they were waiting for their MapReduce to finish. 

It was like, there's got to be a better way to do this, and so he kind of hacked something together and had an intern work on it. Then that because like a fully-fledged team at Google and then there was a time where at Google we were trying to take some of the great things that we had internally and expose those to the rest of the world. I think there was a sense that we kind of missed the boat a little bit by – or we missed an opportunity where we kind of built all these great technologies like MapReduce and Bigtable, and then let other people open source them and then kind of drove the narrative for those. So basically MapReduce became Hadoop, Bigtable became HBase, and GFS became HDFS, and I think we had gone way beyond a lot of those things in the meantime.

Everybody else was sort of kind of following a different path. Building BigQuery partly was a way to sort of externalize this amazing thing we had built at Google.

Brian Dawson: Yeah. It's funny, it makes me think of Kubernetes. So a number of innovations that have come out of Google and the major cloud providers I think speaks to need drives innovation, like in the market and kind of on the – you know, closer to the AppDev, DevOps side, sort of end-to-end software delivery. When I look at all the innovation that has come from teams like yours it's impressive, so I want to say congratulations for your contribution and involvement too, something that should have a wide-ranging impact for a number of your technical peers. That does lead though to another question. When we look at your career path, you made a jump from being an engineer to a product manager and now a chief product officer, which is a gravitas title, by the way.

What was that like? How did that come about? What was it like? Do you have anything to share for either the product managers or engineers on either side of that jump?

Jordan Tigani: Yeah, so I mean with the chief product officer title I have a hard time with that title just because –

Brian Dawson: Oh, sorry. [Laughs]

Jordan Tigani: No, no. It feels like you take yourself very seriously. It is sort of a gravitas title and I have a hard time taking myself that seriously. I feel like as an engineer, when you start as an engineer, every kind of – like moving up the food chain as an engineer the more you progress – you work on more complex problems, bigger, more complex problems with a higher degree of ambiguity. 

Jordan Tigani: And then becoming an engineering manager, there's nothing more complex than a human being and there's nothing more ambiguous than a human being.

Computers always do exactly what you tell them to do, and I think one of the hardest things when I first became a manager was like, people don't do what you tell them to do, and if you start telling them what to do they just get mad and they'll do the opposite thing or that's like the worst possible thing, particularly at Google. If your manager tells you to do something you make sure you don't do that.

Jordan Tigani: Maybe other companies are a little bit more top down, but you really kind of have to learn to get things done in a different way, and then kind of as you build a team and a larger team you could actually think of it as like, well, as an engineer you have abstraction layers and the altruism as an engineer is like any problem can be solved with another level of abstraction. Well, kind of management tiers are kind of a level of abstraction, and yeah, you don't want too many, otherwise there's a problem.

You end up sort of being able to design with teams and you have like these kind of ambiguous pieces that are like the human beings, but kind of together you can build a design the same way you can build a software design, and to me that was fascinating. Then the move to product management is a whole other level of ambiguity because you don't even know what you should be building or why, and there's just a whole world of – then there's all the other weird people out there like sales people and marketing people, and you realize that it's not just about building the best technology, it's building the right technology at the right time, and that was kind of a bit of an awakening to do that.

So, I loved being an engineer but I also loved being a product manager just because I think the most important problems are like what direction you're going in, because it doesn't matter how fast you're going if you're going the right way.

Brian Dawson: Yeah. I love it. There's so much in there to dig into. To pick a piece though, as it came up with one of my last guests, and actually it comes up a lot, but kind of the mantra that I say, "Look, because at the end of the day, whether it's an embedded system that is going on a chip in your microwave or Uber Eats or your web browser, at the end of the day the primary end points for software, there are humans on either side." Right? You're developing software. Humans develop software for humans. So what I kind of heard you say is, you know, it's still an engineering problem.

But there's abstraction, and I'd almost argue that solving the engineering problem solely in the silo of a technical domain risks not really solving the problem for want of a better word, right? You have to consider the human element, and I would like to think – you could tell me I'm wrong here – but that part of the energy from product management as a CPO is you're connecting those domains to make sure that you have a holistic solution, right? We have a technical problem, we have a business, which is ultimately a human need, and you're at the center of that traffic flow to make that happen.

Jordan Tigani: Absolutely. And I think one of the interesting things is that you realize that the decisions that people make to buy a product or to buy a different product, like there's humans that are buying that and humans don't always do things for the best reasons or the reasons they say they do, and it's often an emotional decision.

If you can get somebody excited about a product then they will buy that product, even if it doesn't have all the things that they want or that they expect. And you think that with something like a database that wouldn't be true. You would think with a car of course, yeah, you get somebody's blood flowing and they get excited about like how fast this car can go from 0 to 60 they don't mind that the windows don't roll down or something.

Jordan Tigani: But with a database you'd think that people would be much more logical about what they choose, and it turns out that's often not the case. It's often if you can paint a picture in somebody's head of a world of their data – you know, they have access to data or insights that they didn't have before, they will purchase that database even if it has kind of fewer features than what they're currently doing.

I mean if you look at the movement to the cloud, Teradata is the most fully featured database out there. Oracle is huge amounts of features.

Jordan Tigani: Often when we – at BigQuery we'd say, "Hey, we invented this," and then somebody's like, "Actually, Oracle has had this for years," but we invented this. People see the way the world is going is to the cloud and so they are often abandoning platforms like Teradata for kind of more newfangled, less featured in some ways systems that have far more other things that they can do.

Jordan Tigani: It is still kind of a – you know, it's an emotional decision.

Brian Dawson: Yeah, that's an interesting take, that even for technically-based implementations or adoptions there's emotional components. And you're setting me up for a great segue, but I always have to inject my two cents in for the audience as well as you. I asked are you – I'll just ask to bring the term up – jobs-to-be-done, which I think is an approach, really a holistic approach to innovation, understanding customers' needs as well as a way to establish go-to-market, messaging, et cetera, and drive better user stories, better implementations of solutions to solve problems. I guess I would ask are you familiar with the jobs-to-be-done framework and the jobs-to-be-done approach?

Jordan Tigani: No, I'm not.

Brian Dawson: Okay. Well, that's good. I get to share some information with you then versus just asking. So I'd say give a look, Harvard Business Review – oh my god, in my age I'm forgetting his name – Christensen. 

But jobs-to-be-done I think really focuses not only on the fact that people have logical or functional jobs-to-be-done, but there's emotional jobs-to-be-done and then there's social jobs-to-be-done, and when you're evaluating a solution and what you view as innovation that helps you, there are all of those layers. I have not been able to fully put it into practice but I am a huge fan principally of it. What you set me up for, Jordan, is we talked product, we talked data and the difference, say, between Oracle and other products, so to set the stage for the rest of our discussion can you tell me a bit about SingleStore? I'm curious to hear what is SingleStore but what's new and novel about SingleStore versus why don't I just go to Oracle or download MySQL?

Jordan Tigani: I think the cool thing about SingleStore is it's a database, it's a fully–featured database that can work as a relational database, so kind of like a Postgres or MySQL, Aurora, as well as a data warehouse and analytics data store, something like Snowflake, BigQuery, Teradata. You generally don't have those things in the same package or if you do you kind of have to set them up very differently, but we've built this storage technology. I'm a storage guy so I like to blame it all on the storage technology.

Jordan Tigani: We built this storage technology that kind of allows you to do really fast transactional queries as well as analytic queries on the same system. So if you think about a lot of the complexity in a modern data system it's at the seams. 

It's like you have your operational or your transactional database and then you're moving it to your analytical database and you have to do ETL or ELT and it's kind of like a machine that has moving parts, but the fewer moving parts you have the more reliable it is. Generally with data, any time you have to move your data the more unreliable and the more expensive it is. So kind of with SingleStore you can turn that ELT or ETL into just a T.

Brian Dawson: Oh, wow.

Jordan Tigani: You just transform it in place and it doesn't – you know, when we started BigQuery one of the goals was like move the compute to the data rather than the data to the compute because the data is so hard and expensive to move, and I think SingleStore actually lets us go further and I think it sort of gets into our roadmap and our vision and where we want to go, is we really want to be the kind of the one place that you'll need for your structured data and from the transactional, operational and analytic side.

Brian Dawson: I love that. That's interesting, the thought of this. It brought up an anecdote, and maybe you've seen this, but it was new to me. I was talking to a big healthcare company and someone within their – well, not necessarily within their data team separate function – within their ETL team, only to learn that this healthcare organization, they had a 500-person ETL team. Now notice, that's not DBAs. That's not the people that are actually designing the data and structuring it. It's not the people that are using it or querying it – just the movement of data, to your point, this organization uses a 500-person organization to facilitate that.

Jordan Tigani: I'm going to steal that anecdote.

[Laughter]

Brian Dawson: Right? And the ability to kind of collapse that – I can tell you quietly offline who it is. 

Jordan Tigani: [Laughs]

Brian Dawson: So no, thanks for sharing that. Why is that important, right? What I heard a bit of, and maybe a bit of preamble here, is look, we're able to keep the data in one place, less movement, we're smoothing or flattening, compressing the seam between usage of the data and at–rest storage of the data. How does that align with where technology, where the market, where economy and society is going today? You cannot turn a corner, you cannot join a conference, you cannot read a technical article without discussion of data. Can you tell me one, why are we seeing that, and how does this approach that you guys embody via SingleStore align with that shift?

Jordan Tigani: I think one of the things is it really lets you understand what's going on now as opposed to what happened sometime in the past.

So I think the traditional analytics has been you get data that happened yesterday or last week and you kind of crunch it overnight, you build a report, the CEO looks at the report in the morning and says, "Ah, we've got a problem." That's (a) it's slow, (b) it's hard to actually dig into what the problem is. I think in SRE or DevOps they often ask the five whys, like if something is – you know, the system was down, why? It was because the bandwidth was – we were out of bandwidth. Why?

Brian Dawson: What's your bandwidth? Why? Right. 

Jordan Tigani: And you keep asking why. And if you just have a static report it's really hard to ask why. You can yell at somebody and maybe they'll tell you why, but it's hard to kind of dig into that. 

So I think truly scalable analytics lets you ask those whys and lets you drill down and get the answer kind of immediately so that you can ask the next question. I think there's also – like if you're looking at data that is in the past then you're already behind, and so a lot of people see that it can be a competitive advantage to be able to get the insights more quickly and be able to make their decisions more quickly, sort of data-driven or data-influenced decision-making. If your competitors are looking at data that's a day old they're reacting things with the granularity in days. If you can look at things that are happening right now you can react to those things before they take advantage of it. We see a lot of our customers are in the financial services where time is money is really productized, is weaponized.

But it ends up being useful in things like real–time inventory management, and I even talked to the chief data officer of a European railroad who was like, "I want to be able to see a map of my system – " and the railroads also have fiber optics and they also have queues at kiosks – he said, "I want to be able to look at my system and see what's going on and be able to see where the problems are and see –" and the problems aren't just events, like a sensor going off. The sensor being different than it was at this time last week –

Brian Dawson: It's right there, a continuum or – right. Not just binary problems. _____.

Jordan Tigani: Yep. So it requires kind of analytics as well, so that's the kind of problem that you can now solve, is you can as a business owner or as a business user you can see what's going on in your world, in your business, in real time.

I think that's extremely valuable.

Brian Dawson: I want to flip that a bit too, and I appreciate that and am in agreement, or at least I'm hearing or seeing similar, but what about if we invert it? Because we're often talking about in terms of an industry, which is really important, like your anecdotes. How can data enable a business to compete to be more effective, impactful? How can data enable an engineering team? How can data enable practitioners, the people that actually deliver the software capability and values? Any thoughts on what this additional more rapidly–accessible data provides to them?

Jordan Tigani: Yeah, I mean so just – you know, thinking as a – from my time at Google where I was deeply involved in the operations of BigQuery, data was incredibly important.

Because a customer would report a problem and you'd have to kind of – you wouldn't have access to exactly what – we didn't want to look at the – we couldn't look at the customer's data directly, and so we kind of would have to piece it together through kind of these other indirect, indirect means, through logs, through monitoring, through – you know, we could see, okay, well this server had an out-of-memory condition and had a spike when the customer said that they had this problem, and so you can track these things through. The data's got to be up-to-date because you've got to know what's going on right now, particularly if there's an incident going on, there's an outage; you need to be able to track that down. You need to be able to see is this spike a real problem?

Because sometimes you have weird spikes that every day you have a big – when the UTC date rolls around that really surprises us. The UTC date rolls over at like 4:00 PM Pacific Time, a bunch of new tables get created, and so you see like these weird spikes but they're kind of expected until they're not, until they actually cause a problem.

Jordan Tigani: But kind of you have to put all this stuff together and you have to be able – sometimes it feels like almost conducting a symphony of data where there's all these things that are – you know, you've got thousands of machines and all these logs and all this monitoring and you kind of – when you know it well and when you have the right tools you can really just have this matrix-like feed that can give you a pulse on what's happening. 

Brian Dawson: Yeah. You made me think of two things, one directly from what you said and then another coming in. 

One is just cognitive load, right? Like the amount of time, whether you're in operations or development that you end up trying to derive meaningful correlation and relations between disconnected sets of input data is a lot, right? At least in my – not to confess to everybody, I actually haven't opened an IDE in longer than I like now, and the fact that – so if you have rapid access to a single store of this information and you can rapidly investigate different relationships you're enabled, and then I think the other is context, and I'll share that in some of the work I had done we really tried to look at developers, application software developers, and what they needed to feel empowered. A word that came up a lot is context. I can better solve a problem if I have access to the context of the problem, and I heard a bit of that in what you're saying, which robust data can provide.

Jordan Tigani: Right. Absolutely. 

Brian Dawson: How has COVID – right? I mean there's no getting away from the fact that we're in the middle of a pandemic and it has affected our lives in a myriad of ways, some yet still to be determined. In your space, have you seen or do you have an opinion on how COVID has changed data, data management? Are tech companies asking you different things now? Do they have different needs? What do you see?

Jordan Tigani: I mean I think digital transformation is a bit of a buzzword that gets people to sometimes roll their eyes, but the mechanism is real, like the moving to cloud, moving to a data-driven or data-influenced decision-making, and I think COVID has accelerated that. I think a little analogy is flying a plane.

And there's flying with visual flight where you can actually look at stuff and you can see whether you're over the runway or not and you can see whether you're upside down or not, and then you fly into a cloud or in a fog bank and you have to go on instruments. And I think what COVID has done is really kind of – we're in a fog bank now because we can't use our senses, our normal senses to see what's going on. Just the cues, like how full is the parking lot or how do people sound in the breakroom or how excited are people's eyes at the conference that you go to? There's a lot of cues that we're just missing because we're not in the office and we don't have the same interactions that we used to.

I think business leaders are having to kind of fly on instrument mode, and instrument mode requires data, and so that's causing them to sort of accelerate the movement to making data–driven decisions and data-driven operations.

Brian Dawson: I love the fog bank analogy, and I'd ask do you also apply that to not only the fog bank, right? We don't have the signals that we usually get physically, but is it true to say that we're just in an unknown space now, so sort of the business and market fog bank is there as well and people are seeking data to help them drive through that landscape?

Jordan Tigani: Absolutely. Yeah, I mean things are changing. Patterns that had been established and had been the same thing for 100 years are now kind of rapidly changing.

I think the only way to really understand that is through the data. 

Brian Dawson: Awesome. You talked earlier – and again, this is about you, not SingleStore, but we're also talking about the market where first I'd like to ask do I have the ability to share today's news for SingleStore as I transition to this next topic?

Jordan Tigani: Yes. Absolutely.

Brian Dawson: Okay. I'll just do it by saying congratulations. I happen to notice coming in that today you just posted that you just received $80 million in additional funding to help you guys solve problems, so congratulations. 

Jordan Tigani: Thanks.

Brian Dawson: I think that's a sign that some of the stuff technically and market-wise we just talked about earlier in this session, people see merit to it. What we also saw earlier this year is a company you mentioned, Snowflake, have an amazingly successful IPO.

When I look at the stock price I'm blown away. What does this indicate for the industry overall in your mind and for the data industry, the data market? 

Jordan Tigani: I think it's a recognition that the market is absolutely enormous. I think in their SEC filings they said the addressable market is something like $80 billion. It's growing quickly, and I think that – I mean they're only around half a billion dollars in revenue in a market that's growing to $80 billion. There's just a huge amount of upside, there's a huge amount of growth, and so I think that we're still in early days of the migration to the cloud, kind of this new generation of databases, data management systems, and I think it's caused everybody to look again. 

Databases are sexy again. I'm not sure they were ever sexy, but certainly with some of the numbers that are being thrown up by Snowflake, people are like, "Hey, there's something here," and I think we're getting more interest than we had, but I think that – our CEO likes to say there's likely going to be $1 trillion in market cap created in the next 10 years from database companies, and so, yeah, there's still – a lot of the race is left to run.

Brian Dawson: Yeah, yeah. I love it. It just dawned on me as you were saying that, which is a testament to you and I'd also like to think a testament to the podcast, it's going to be one of the few places where you're going to hear conversations about transaction speeds and seed rounds of funding.

On the same topic you're going to hear about OMEs or out of memory errors and market caps, right?

But it's all connected. Just to add, you talked a bit about futures, but we're about to be done with 2020. Thank goodness for most of us. Moving into 2021 there's a real movement towards data and a real change to the way we review architectures, the way we review software delivery, where we host things how we run them. Bringing that all around back to data, what do you see trend-wise emerging – what should we see around data in 2021?

Jordan Tigani: So I think for a while there's been for big data – and at first people were like, "Well, how can I just store all this data?" And then it was like data's coming so fast how can I hook up this firehose to the data?

And then I think we're still not quite at the phase where people can really make use of it well yet, and I think there's one remaining – the remaining step is how can I make sure the data is good, is right? I think there's a bunch of different ways of kind of solving that problem, but if you're going to make data-driven decisions, if you're going to make data – like you've got to have confidence in the data, and so much in data is just noise and it's really easy to make a bad decision. I was looking at a postmortem the other day for a brief outage and kind of we're looking at the wrong signal and we're deriving that this was the problem.

Because it seemed like, hey, there were these spikes, but they weren't actually the problem. The more you're relying on data the more you have to develop these filters. I don't know exactly how we're going to do those, whether it's kind of adding semantic modeling to the data, better kind of machine learning, data cleansing mechanisms, but I do know that it's to my mind an unsolved problem in data management.

Brian Dawson: That is key. Data can be used in anywhere. I think sometimes us in the engineering field, there's enough confidence in our logic trees and our of assessing the data that when we attach to one of those spikes and decide that it's a cause we can figure out – we can apply logic to justify it.

You bring up an interesting thing I saw in another kind of side conversation, a conversation I had in my day job, and they were – and I'm curious if this is a way to achieve that confidence level – applying machine learning that was – it was targeted towards operational or ops engineer system admins doing diagnosis, and what they could do is analyze the data, derive a hypothesis, try to use the data to solve it and then effectively – and I'm saying this clumsily – then input a score. Or the data would support a hypothesis, they'd investigate it enough to solve the problem, they'd score it. Any thoughts on – because what it sounds like, the problem is we need to ensure that that gap between what we see in the data and how it's applied to solve a problem, we minimize risk in that.

We increase confidence and minimize risk in that translation – is human-led scoring in a machine learning model, a viable way of addressing that in your mind or any thoughts on that, because that made no sense, Jordan, by the way.

Jordan Tigani: No, I think that's really interesting. I think it's going to be really hard for a machine to automatically apply fixes, at least in the near-to-medium term, but being able to have a machine learning that's trained to recognize when something is going out of whack, recognize kind of that like this spike is normal versus this spike is not normal, I think machines are going to be able to do that a lot better than humans can, especially in kind of the heat of the moment, in the heat of like – let's say there's an outage. 

You pull up a graph that you're not used to looking at, you see a big spike. You're like, "Oh, this is the problem," and then you kind of – you may spend a lot of time kind of trying to diagnose that and not realizing that that's a periodic spike that has happened, you know, every Thursday.

Brian Dawson: Right, right. So to the fun questions now. We do something on DevOps Radio called Dev Ooops, Dev O-O-O-P-S, Dev Ooops, and it's a challenge in software development, technical or even career–wise that you've faced, you overcame, you maybe even hopefully embarrassed by it initially just to make it more meaty – you've overcame and it served as a lesson for you and hopefully for our audience. Do you have a Dev Ooops moment you can share? 

Jordan Tigani: Yeah. I think one interesting one – so BigQuery had a streaming ingestion service – or has a streaming ingestion service. I helped build that.

It had a bunch of scalability problems, and so we had a lot of – it was growing really fast, and I think obviously if you have a high QPS service, it's growing really fast, and you kind of – you run into problems. We had one day, one afternoon – you know, one of the things you could do is it was tied up to Google login. So every time you do a log statement in your code it would cause a streaming right. One afternoon SnapChat turned that on for all of their rights, and so it was Friday afternoon at 3:00 PM and they added 4 million QPS to the system, and that was a lot at the time for us.

Jordan Tigani: That caused all sorts of cascading failures, failures where we'd actually – one of the things about a streaming system is that it's almost indistinguishable from a denial-of-service attack because if you're sending – because let's say you have IoT and you have thousands of machines or thousands of things that are all sending these individual streaming requests, so it's distributed –

Brian Dawson: It's just too big and nondeterministic I guess too, when you say it looks like DDS. So you could at one time have a significant spike and have – I don't know what the scale is – hundreds of thousands if not millions of IoT devices making simultaneous requests. Is that–

Jordan Tigani: Yes. So we kind of had to disable a lot of the normal DoS check that we'd otherwise build.

And so that was – I think that component, in order to fix that in the middle without causing outages was a major – basically we went into something we called Code Yellow at Google, which means that you basically can't build any new features and you have to kind of focus on sort of solving a reliability problem and we kind of rearchitected the system. One of the key insights was as you're building a system you kind of assume a sane user or you kind of assume that I don't need limits on this, this is virtually unlimited, but then you realize that as you start to scale and as people are using your system people will use it in all kinds of weird ways and they knock –

You know, if you can be knocked over they will find a way to knock you over. So we basically went in and we put all sorts of limits on things where we said like, "Okay, well the largest number of columns in a field is allowed to be X and the largest rows allowed to be Y," and all these things were kind of preemptive to prevent – because it was a large, multitenant system and we didn't want people to be able to knock each other over. Because it's one thing if SnapChat does this and it knocks over our servers and it only affects them, but if it affects everybody else too then that – you know, we had another one where we had an outage on the night of the election in 2016 and our streaming system – like the New York Times was using our streaming system and that was a difficult evening. 

[Laughs] It was a difficult evening for a lot of people, but it was a difficult evening. And so anyway, one of the ways we solved it was adding limits even where we thought we didn't need them, and I think one of the things we learned then subsequently after that is that there may be better ways than adding limits to things. If you can add pushback mechanisms, if you can add isolation mechanisms, and if you can just even make part of your cost model so that people who kind of cause some of these problems, they end up paying more, then they're incentivized not to do some of these kind of more egregious things.

Brian Dawson: Yeah, that triggers a couple of things. One is I know Walmart, when I was trying to get a PS5, needs to do something better with their queueing of their –

[Laughter]

I'm going to give to friends at Walmart apologies, but there's – what is it called? Discouraging design. There's this field called discouraging design, and I may have that first word wrong – I'll have to Google it after the fact. You've seen a lot of it in Europe where you – say they want to stop skateboarders from grinding on benches so people can actually use them. 

They will design the bench in a way that not only that it functionally compromises the discouraged behavior but it visually and psychologically discourages it. So it's using design not to make the most beautiful and functional thing, but using design to disincentivize the undesired behaviors, which sounds sort of very similar to the financial disincentivization or other layers that you could put on top of the user interaction to help steer behaviors.

But what I hear you say that I'll repeat back because I think it's important is the way people will use your service or product is not deterministic and you need to be prepared for the unforeseen. Is that fair to say?

Jordan Tigani: Yes. Absolutely.

Brian Dawson: Can I ask another common question? I assume that with your tenure and your experience in various fields that you have some beloved resources that you gain knowledge from or have gained knowledge from, gave you insights or learning. Can you share with our audience what one of those resources might be, whether it a book, a podcast, somebody you follow on Twitter? What resource would you recommend they go out and look into today?

Jordan Tigani: I'll avoid the trap of giving my own book, but…[laughs]

Brian Dawson: But, check out his book, right? 

There's actually a coding book that I thought was incredible. It was called The Little Schemer, and it's written as a child's primer and it just basically starts with – and it just kind of gives very little schemes – very small scheme snippets and then kind of a comment about what it does. It starts off from like the most edition, and kind of builds up from there, but it's just amazing how with these tiny, tiny little steps you can get to then by the end some very, very complicated algorithms and some complicated things that it was doing and just kind of makes you think differently – like to me recursion is fascinating, streams are fascinating.

I was really into functional programming for a long time and could destroy any conversation by talking about functional programming for hours.

Brian Dawson: [Laughs] Don't invite the functional programming guy to the party.

Jordan Tigani: [Laughs] Exactly. I'm now a reformed functional programmer. I thought it was really neat, and kind of what led me there was like the Structure and Interpretation of Computer Programs, which was a former MIT course that also just sort of – even as somebody who had been coding for 15 years, like when I read that – and actually I saw the original videos, which are fascinating – they made me think differently about coding. 

Jordan Tigani: And even though they were an introductory course it made me think like that there was a different – that there was another side of the matrix that I just hadn't had access to before.

Brian Dawson: Wow. Awesome. That is probably the – this book showed me the other side of the matrix is – that is a heck of an endorsement. So the source on Little Schemer.

Jordan Tigani: The Little Schemer.

Brian Dawson: The Little Schemer. Okay.

Jordan Tigani: The Littler Schemer and the other one is Structure and Interpretation of Computer Programs.

Brian Dawson: Yeah. Structure and Interpretations. I think I read that some years back, but I'm noting because I actually often just go on and buy these books right after the show, so I'm excited to see Little Schemer. That seems novel. So I'm going to ask you final thoughts, right? This part of the episode, there's standard things we ask. I want to ask you in a different way to see how it works, right? What are your final thoughts? If you were to share final thoughts with IT leadership, what would your message be as opposed to final thoughts with engineer Jordan, right?

Technical practitioners. Do you have messages that you could share with those two personas?

Jordan Tigani: I think to IT leadership is good data is really important and don't trust your data until you really understand it. I think maybe – we were talking about machine learning. Machine learning might help, but there's something for just kind of getting a feel of it. I think some of our best SREs, they could really understand what was going on in the system and then they would know how to react when there was a problem. 

I think as engineer Jordan or just from a career advice perspective, I would say that I think just don't be afraid of change. Sometimes a change of perspective is what allows you to kind of take the next step or get to the level that you were shooting for. 

Brian Dawson: Awesome. So, Jordan Tigani, Chief Product Officer of SingleStore, thank you for your time. I really appreciate it. I enjoyed the conversation. Hopefully we'll get a chance to talk again soon, and best of luck on the rest of your career and best of luck with SingleStore and your future, their future.

Jordan Tigani: Thanks so much for having me. This has been fun.

Brian Dawson: All right. Thank you. Likewise. 

\