Ep. #17, Standardizing Work with Sam Ramji of DataStax

Patrick Woods: All right.

Sam, thank you so much for coming on the show today.

Maybe we could start out by just hearing a little bit about who you are, what you're working on and how you got into the wonderful world of developers and communities.

Sam Ramji: Thank you very much for having me. It's a privilege.

Who I am, I'm Sam Ramji. What I'm working on is a bunch of things.

I'm the Chief Strategy Officer at DataStax, which is a Apache Cassandra commercial software company.

Also, working on Data on Kubernetes.

I'm extremely curious about data meshes and generally where the world's going over the next 10 years as we become more and more of a data driven apps kind of world, rather than app driven data.

So how did I end up in the wild world of developers?

Well, I started out as one when I was nine.

So in 1980 I started programming and that was pretty cool.

And it was kind of by me and others who did it at the time, we took it so much for granted.

We never thought of it as a job.

I ended up kind of being the unofficial TA for the AP computer science class in high school, which again, it was the '80s so it was Pascal.

And I ended up going to UC San Diego pre-medical because, again, like most of us didn't think of software as an industry or a job or something that you could go into.

But then when I came through school I was like, okay, I want to build educational software.

So you could either be a product manager or you could be a developer and I was like, well, I'm going to go be a developer.

So I spent several years engineering.

I love C++. Don't get me started on Java or C++ versus Java.

I'm still sad about how that worked out. And then I worked for developer platform companies.

I worked for BEA, the Java company.

I worked for Microsoft for several years.

Worked for Apogee, which was the API company. We took that public in 2015.

Worked for Cloud Foundry, which is a developer platform in open source, it runs on multiple clouds.

Then I worked at Google as the Head of Project Management for compute and developer.

So I was VP of PM at Google from 2016 to 2018 working on Kubernetes and on Kubernetes-based devops and then I tried to apply that to my last job at Autodesk where I ran the cloud platform team.

It was about 1,100 engineers in I think about 40 locations, a dozen countries supporting Autodesk's need to become a data company.

And so, all that stuff has kind of lead me in my curiosity to building open cloud hybrid data platforms that are good for SREs and operators and that are good for developers.

Patrick: Fascinating story there.

You mentioned data driven apps versus app driven data.

Sam: Yeah.

Patrick: Could you unpack that a little bit?

Sam: Yeah. So we tend to work right now in a world of application driven data or app driven data.

So where is the data? It's stored where the app want it. Where does the app want it?

Well, it could be on your device or it could be in a microservice.

Well, what are they storing the data in the microservice in?

Well, who knows, it could be in MySQL, it could be Cassandra, it could be Mongo.

Okay. If you're not the app development team and you want that data for something else, how do you get at it? Well, that's an afterthought, right?

Because the whole focus of our world is application velocity. Get the app, ship faster, get them iterated faster, get them updated faster, keep the developers happy for sure. Keep that moving fast. As a result, it's pretty hard to get the data out.

So you end up with, how am I going to migrate the data?

How am I going to load it? How am I going to transform it?

Who needs it? Do I put it in a lake? Do I put in a warehouse? Who knows, right?

Data driven apps, though, are the flip side and it's almost like the difference between writing a recipe and following a recipe for cooking, that's kind of how I grew up.

Procedural application development that emits data and interacts with them, to something that's more like training a pet.

How would you train a puppy, right?

So data driven apps are really ones that the behavior is rising from a set of data that you have a set of algorithms that are learning.

It's interpreting the data through human activity like you've put labels, right, you've got data pipelines that tell you what this data means.

Like this is a giraffe and that is a tree, right? How do you distinguish that so that the machine can learn?

Those machines that learn also have learning errors, we call it drift or skew.

So it's quite a difference, more of an organic kind of model of thinking about what is an app in a data driven apps world, it's almost emergent.

Not precisely so but something like that, versus what is app driven data, which is what's more predictable and predictive.

I know what it's supposed to do, I know who it's supposed to serve and I'm going to iterate that.

Patrick: Love the metaphor of recipe versus training a puppy.

Sam: It's a useful one, right?

It's very hard for people to move from their excellent skills at application driven data, right, and procedural programming over to this strange new world where it seems like Non-Euclidean geometry, up is down and down is up, what's happening?

So there's a little bit of a frame of reference.

One of the fascinating things that's happening is that the two are starting to meet and people want a little bit of AI or ML, whatever you want to call it, pattern recognition that's changing dynamically in their app.

A really simple version of this would be how awesome is it that you have autocomplete in Google Search, and you don't just have one suggestion, you've got a range of suggestions.

That's pretty cool data driven app behavior showing up in an app environment. Makes you smarter.

It learns as trends change, lots of different people are asking these questions and you can actually watch Google learning through autocomplete.

And you can think of it, and I think this is powerful, you can think of it as a UI over Google's knowledge graph.

So there's a way of starting to bring these two worlds together, right, and you start to see some of the interesting things about how you get different types of developers to work together, understand each other.

And how you get these sort of evolving systems to do something really cool for users.

Patrick: So I'm curious about your perspective on developers, how that's evolved over time about what they need, how to empower them, taking into account the various roles you've had from the age of nine, learning to program to today.

Describe that arc of your understanding of the developer over time.

Sam: So funny.

I think it's partly a historical map and then partly it's just a lifecycle that anybody would go through, right?

I think the first fascination for me is, oh my gosh, I can get this thing to do exactly what I tell it to do.

I can use some of my knowledge of logic, maybe a little bit of math and it can do really cool things for me.

How amazing. I think when you're a kid, right, you are at the mercy of so many other people, right?

Where are you the master of a universe? It's really important to have your own sandbox that you can build in.

So I think that first step is like, oh my gosh, look at this, I built this thing in my sandbox. Right?

Then once you get tired of building things in the sandbox you still want to build things but you want them to connect, right, to the real world or however you define real, right?

It's some domain of care that you have.

So how do I get that afferent behavior? How do I get outcomes from what I did in my sandbox?

And I think the much later stages are like and how do I get that thing to be a full loop, right?

How do I get the real world to then come back and inform the next thing I'm doing?

How do I keep iterating at that? Kind of scaling up over time.

I think one of the things about being a developer is always curious, never satisfied.

Right, if you think about the persona. At Microsoft they used to say, "We hire insecure overachievers."

I guess another way of talking about a developer persona.

You're just trying to do more, you're trying to change the world.

You've got some crazy idea you want to see if it works, and you'll feel better about the idea if it does work and if other people think it's cool, too.

So there's a sense of that underlying, I think, childlike curiosity that makes life as a developer so fun and satisfying.

You are paid to learn and you can keep learning it vertically, you can learn at bigger and bigger scales, become a principal engineer, work on architecture or horizontally just learn more things.

Like hey, maybe you started out in ray tracing and now you're super interested in database workload scheduling algorithms.

Cool, there's plenty of room to grow as a developer, that's why it's such an amazing job and such an amazing community of people and just an amazing career.

Patrick: So thinking about the role of communities or community as a concept in the context of that development, that progression, what's been your experience in the overlap between developer communities and the developer's themselves and maybe the companies that participate in those ecosystems as well?

Sam: Yeah. It's like are you looking at the parts, are you able to sum them back into a whole?

How do how they connect?

Then one of the interesting sum of the parts and the wholes is can you connect your go to market and how you think about measuring success as a company with your go to community?

Can you think about those two things equally? Are they symmetric?

How do you think about the ratios of how you expect outcomes to be produced?

How do the two time sequence each other? Does a healthy community tend to produce a healthy business?

Can you have a healthy business without being preceded by a healthy community?

Can you bootstrap it later? I really admire companies that are built out of people who fundamentally understand how these things work.

Often those companies and people who fundamentally understand how they work don't have the science to write it down.

It's almost an embodied knowledge. A bit about riding the bike versus being able to write out all the physics of why the bike works and how it could fail.

So we end up with really, really great companies being repeatably produced by people who really understand developers and how they constitute your business.

And then we have a bunch of other folks who are like hey, prove this thing about developers.

No, explain the technique. No, measure it. Don't tell me that you just need five more community leads.

Explain to me in dollars and cents how this stuff works.

You see these conflicts often at change of control, you get a new CEO or maybe you've got a new strategy in a company where you've got a very sales focused culture. And the balance of power is always in people who can measure their activities and have a good story about how those correlate with results.

And one of the big gaps for the go to community arms of even great companies is the ability to measure what they're doing versus the outcomes.

So I think balancing this fundamental sense of what it means to go to market with not just an embodied knowledge, but a scientific knowledge of how to go to community is super important.

I learned a lot about this at Microsoft where they had built a company really on developer experience fundamentally.

And when you look at how companies behave and how people care about things, they tend to care about what gets you paid.

So at Microsoft there was a balanced scorecard, it wasn't just revenue.

One of the huge elements on the Microsoft scorecard was dev tracker, which is a combination of developer satisfaction, NPS, a few other components bundled up into one number that every executive at the company could look at and know it was going to change the compensation.

So it turns something that is often fuzzy and feel oriented into something that even the folks who want to be able to manage the company on a spreadsheet can see it and say, is that number going up or not?

And then you can start to balance that conversation instead of saying, hey, I need five more community leads.

You could say, in a population of this size, right, we've got Brazil and we need to increase our dev tracker score by four points this year.

That really means this many more human beings applying themselves to these roles using our technology.

Typically, we see that we can have a community lead per let's say 100,000 people in the population.

We want to reach another 500,000 people, I need five leads.

Those kinds of conversations move into equal footing with everybody else who's trying to get a piece of company capital, whether it's marketing or sales or product or engineering.

Patrick: That's amazing.

So at Microsoft, with dev tracker in particular, was the dev tracker aligned in the scorecard across all executives or from certain business units, or what did that look like?

Sam: That's the beauty, every single executive.

And when you look at the intentionality of that structure, at the time that I was there, we had about 80,000 employees.

We're around 60 billion in revenue, and the top 120 people in the company, people with the title Corporate Vice President, right.

These are the folks who are alternately running product units, running really big functional organizations like marketing or running regional sales organizations.

We had a Corporate Vice President for Africa, Corporate Vice President for the Middle East.

So large regions, all of them were uniformly compensated on this balanced scorecard.

Which I think was Microsoft's breakthrough innovation in corporate governance to be able to balance these two sides of what makes developers incredibly engaged and happy with what you're doing, and how does that turn into a sustainable business.

Patrick: Yeah. This is getting in the weeds a little bit, I guess.

But I am curious about the inputs into dev tracker, how are those inputs validated in the connectivity between what was in dev tracker to what actually moved the needle on the business side of things?

Sam: That's a great question, because that was what enabled me to do the work that I was doing in open source at Microsoft.

Change at any big company isn't going to happen because you think, "Oh, my gosh, I got this great idea. Everybody's going to be in love with it."

It happens because you can show the connection between this new idea and it's differentiated ability to hit the metrics that you've already been told to hit as a company.

So inside dev tracker, it was a pretty neat and substantial cross company process.

But it was repeatable, which was why it was useful as a tracker quarter-over-quarter, year-over-year.

As I mentioned, it was a combination of developer set so it's like a customer satisfaction survey.

So we ran surveys, NPS or net promoter score, so that's also bundled in the survey.

And then a set of instruments showed us how many people are using this technology versus that technology in the market.

So we would buy data from IDC, we'd buy data from Evans Data Corporation.

And then with all third-party information, you always have to triangulate it so you have your own view of it that you understand and believe in.

Because if anybody starts to question the reality or the metric, then the whole thing falls apart.

By the time I got to Microsoft, this was well understood, I learned it there and it was generally accepted.

And one of the things that happens there when it's generally accepted is it's standardized.

And standardized things make you smart because now we don't have to have the whole conversation about how do we know, right, the epidemic argument.

We can just say, how's it going? And all of a sudden our conversations can get super efficient.

So we also did a bunch of in depth interviews in dev tracker, this is where my open source story comes in.

And to use the example of Brazil, which was a live example, we found that a lot of developers had particular feelings about Microsoft and about non Microsoft technologies.

One of the biggest opportunities that they surfaced was, hey, we really, really like PHP.

This is just an amazingly strong PHP company.

PHP runs really badly on Windows and it runs amazing on Linux.

And so, when we choose PHP, we put Linux with it.

So then that starts to give you the depth of view from dev tracker.

And says, hey, what if we made that work really well? What if PHP on Windows was amazing?

And then could we take that back into Brazil and communicate with developers there and say, PHP on Windows, who knew?

How do we help you try this out? And does that make a difference to our business? Can that move share?

Because now when you pull PHP is there a chance to pull Windows instead of Linux?

So these are the kinds of things that you can pack into a really disciplined dev tracker, there should always be room in that instrument for some novel strategic questions that could offer some kind of cool insight.

Patrick: Love that. So our audience contains many early stage founders of developers tools companies, API platforms, open source, open core.

I'm wondering how you would translate this approach that worked at Microsoft on a global scale down to a seed stage or a series a company.

What advice would you give them for creating something similar that's stage appropriate, but also equally as powerful for their purposes?

Sam: Sure. I think a great question is always who is using my product that I don't know about?

When we think about where web API's came from as an industry, right.

I spent too much time on that in Apogee and I had to ask myself the question historically like, why is this happening? Who's using it?

We found that the best signal that somebody that you didn't know was using your stuff was that they were using a web scraper, and they were turning your website into an API.

That's super interesting, right?

You can either shut that down, block the IP address or you could be like, "Oh, my gosh, somebody is using my service to do something I didn't anticipate."

This is a signal this might be an opportunity.

So it's an orientation, right, as a management team to look for these novel uses outside of what you thought.

Because in my experience, and I'm in my sixth startup now, people never use your software for what you thought they use it for.

And when they start using it for this other thing enough, that's actually the shape of the business that you're meant to be in.

So think about developers, especially ones that you haven't heard of, as opportunities for you to get a new view into your future.

Now, these days you've got companies that are assuming that API's are going to be part of what they offer their customers.

So most companies that are providing a service have some level of customization or interaction that they expect developers need to work with.

So in those cases it's more an extreme version of what I was describing before, don't just kind of watch what they're doing, but actively serve them.

Ask what are their use cases, make sure that you're talking with them in depth.

And this is where you can actually use anecdata at the beginning.

You could say, okay, if I have 20 pieces of anecdata, somehow that's a data corpus.

Do I trust myself to have a field to work on developer product?

Have I work with other people who've done this before?

The final piece would be developers are your primary audience.

And in that, you're going to really tackle this as the whole structure of your business.

You think of the developer is the buyer and the user, you apply a lot of your fundamental marketing and product management techniques that you already have but looking at the developer.

In all of these cases, I think the great metric is active developers.

Now, depending on your product, you might look at daily active, you might look at weekly active, you might look at monthly active.

Define those things the same way you do as our service.

You shouldn't look at just the interactions the developer has with your UI. UI, because mostly a developer would prefer not to use a

So that might be a part of your signal. But a database or an application tier that hasn't been modified in several months, it's much more important that it's serving traffic.

So how do you look at that other component, right? Is it your apps? Is it the interactions?

What is the interaction that you want people to have with your platform?

That's a super interesting thing to measure no matter who your user is.

If developers are also your user, you want to measure your active developers over time.

So that you understand just like a sales channel, are they converting appropriately from registration to use?

Is their level of use deepening?

Make sure that as you do this, you've got enough signal in there that you can disambiguate developers from each other, that you can look at the movement of developers across projects, that you can look developers within orgs, that you can look how orgs connect.

A great way to lose all this information is to conflate it either by not knowing the difference between several different logins from one developer with different unique names.

Or by having a identity model that is too naive and doesn't anticipate the sort of multiply inherited nature of a human being, right.

You can have multiple classes, don't get me going on C++.

Or the change over time of people, projects and companies.

Patrick: That's fantastic and immensely applicable.

We shipped in API with essentially version point one of Orbit and have learned an immense amount from our early users and how they're using in some cases, not quite abusing it, but are using it in creative ways.

But it's such an immense surface area for learning for us as we think about the product.

Sam: Right. So treating it as such means instrumenting it because pretty soon you're going to be looking for the outliers because there'll be more interesting than the core signal.

Can you find the outliers? And can you see this as it scales?

So if you don't do this, if you don't have that orientation towards, hey, let's have telemetry, let's treat this as signal.

Then you're going to be back in the world I described where people kind of know how it ought to be, but they can't prove it, right?

They've gotten the equal, but they don't have the quants.

And in any coherent managed corporation that grows over time, the quants are always going to have the upper hand because you have to decide where to put your money, and who to hire.

All right. As the CEO of Orbit you know that, right?

Patrick: Yeah. That's right.

Sam: How managing capital is the CEO's one core job that nobody else can really do. Right.

They can never step away from that. So the ability for the CEO to make the good decision, hire one person here versus hire one person there, that's got to be backed by data.

So if you start out by not collecting the data, you won't have the signal.

And you probably won't have the right culture because you'll end up with people in your developer community team who all get along super well and they use a lot of jargon, but they can't do the entrepreneurship move of explaining to other people in a compelling way, right, with both the poetry and the numbers about why this is a good idea.

Patrick: So you tweeted something recently that I want to read.

So I'm going to make you listen to a tweet that you wrote, but then have a question about it.

Sam: Is this going to be like celebrity mean tweets? I don't think I can handle that.

Patrick: No, this one was great.

So you said, "A good tool should standardize work. If it standardizes that work in the right way, it should create more competency for the user. Systems of tools should teach us how to collaborate. If they define collaboration in the right way, they should create more harmony for teams."

So I'd love to get your perspective on how the most effective tools standardized work and they teach us about collaboration.

Sam: Yeah. The creation of a good tool is a lot of cutting out of negative space, right?

The fact that hammer is a hammer and it's not a drill.

Somebody put a lot of effort into thinking through, right, how does this fit the hand? What does it do?

I'm sure we could all design a better hammer, but we have the hammers we have.

But a hammer is a pretty dumb tool. It gives us a little bit information like when you hit your thumb, don't do that.

But it doesn't tell you that much about how to do the work.

So as we think about smarter and smarter tools, and we have so many these in technology, they should by design take a bunch of choices away from you.

Because it turns out chaos, that doesn't help anybody, right?

You want to eliminate a whole bunch of non meaningful choices, so that we can spend our limited heartbeats quickly doing things that matter.

Design is a lot of that removal of choices. They say design is done, not when you can add nothing more, but when you can remove nothing more.

So I think that's a lot of the good tool design.

Building more competency for the user, I think ends up being that same thing iterated again and again.

The more that I use, let's say Google Docs, the more that I can see other people interacting in.

I can see when I'm stopping on something, I know when I'm creating more space for other people to participate.

I know if I'm using suggestions versus editing mode versus comments, right.

There's a surface area constrained enough to be useful.

But it also teaches me a bit over time, how to become more competent not just as a writer but as a writer of shared collaborative documents, there's bits of feedback in their.

Twitter in a way helps you become better at using it because you have feedback right in the tool, right?

You have your likes and your retweets.

So at least for you as a situated being, you can grow competency at that thing, right?

Hopefully use it for good, not for evil.

But that's an ethical question, not an aesthetic one.

So that's a core piece there.

When I look at companies like Atlassian, surprisingly, if you look at SAP, if you look at Microsoft Office, you end up seeing a whole bunch of design choices about how work autoflow.

Some really great tools like Concourse, if you think about that as a visual code pipeline tool, it takes a huge amount of choices of how you might think about the problem of shared collaborative code development, and what is good state versus bad state.

It takes that right out. And it gives you a visualization of what is the state of work that maybe previously you had on whiteboards.

Or previously, maybe only the release engineer was able to construct in their own mind.

And now we can all see the shared state of that thing. That's amazing.

So when we see that something goes from green to red, we can all step in and we can create a practice around that and say, okay, what was the root cause of this going red, let's make sure that doesn't happen again.

And it creates space for particular conversation.

There's probably even more higher competency ways to come after it like we have in sort of the DevOps or the SRE manifesto of sort of blame the process, not the people know.

No grumpy humans, let's do this as a blameless post mortem.

Whatever that human structure we put around in it, it's all enabled or disabled by can you see the build process?

Can you see the pipeline? So CircleCi, Concourse, I think a lot of the DevOps tooling that we're seeing or some of the shared observability tools.

Note that I said shared observability tools, because they're trying to standardize work for a number of people to all come together around, maybe a production down or a production downgrade incident, and that requires collaboration.

So it pulls us in no particular shape.

Rather than us going crazy pulling a whole bunch of log files, flinging around, imagine if you would the farthest pace from the happy center, that would be a perfect tooling experience, you'd be on tattooing.

You'd be drowning in spreadsheets, you'd be arguing with graphs, it would all be Excel and you'd be using an ancient version of Windows that made it really hard to look at the same thing with no compatibility.

That would be bad. That would teach you risky, bad ways to work.

But a good modern tool in DevOps gives you shared transparency of the problem from a very opinionated point of view.

And I think that teaches us how to have more harmony because we have already agreed on a problem definition and a visualization mechanism, and now we can just get after the getting.

A little bit like what dev tracker did for Microsoft, it helped standardize work.

And it encouraged forms of collaboration that would move that number and encouraged thinking differently.

Even things that they hadn't designed in, but we could make a common argument that said we should embrace open source on Windows as a marketing campaign, as a technology because we have the shared outcome of dev tracker and we need to move that score.

Don't trust us forever, let's run this for a year and see if it moves.

Patrick: It does seem like for tools to fully self actualize, they have to have an opinion about the best or the ideal way.

Sam: It's incredibly generous to be opinionated in a tool.

Because without opinionation, you have a tremendous amount of cognitive load.

So let's imagine the only tool you could possibly have for the rest of the operation of your business is Google Sheets.

Well, that's great. It's almost unconstrained. It's almost unbounded, right?

You can call out to other languages, you can create a Turing complete model of your business.

But what did you decide? What did you choose was in, what was out?

That's a team decision for every single team that solves a problem, and maybe for the same human multiple times a week.

What do I do? So to start to standardize that work, says, I'm going to do the cognitive load management for you and I'm going to hand you something as simple as a pipeline.

Everybody can visual left to right pipeline.

Is it a sales pipeline, is it a production pipeline, is it a supply chain pipeline?

I don't know. But now I can see the flow of things over time, and there's a set of stages that have been chosen.

And so, now, I'm assuming this is competent.

And I don't have an MBA in this stuff, but I've got my one A.

You got educated on how the work ought to be done because you can see this opinionated tool.

So that I think is kindness. It's also kindness because it's competing in the marketplace.

If you don't like the opinion that was rendered by this firm, that's fine.

Pick your own, right, you have agency.

But manifesting your point of view in specific design, taking a whole bunch of different ways to solve the problem off the table and just giving people a good view of how you think all that got to get done, that's really helpful.

Patrick: I love the view of choices, kindness.

And I'd like to shift gears a little bit in here a little bit more about kindness for you, and how kindness as a philosophy has been a big part of how you carry yourself to the world.

Sam: Yeah. It's something that I think all of us have, an unbounded ability to get better at, there's no perfect score.

And I think, for myself, every time I look back a few years at any given piece of my own history, any interactions I've had, I think the ones that I regret were like moments where I think I could have been more kind.

If I just had to look at more of my presence, maybe a little bit less of my ego, a little bit more breath, there's almost always a way to go back and do it better.

And I do think the directed path is kindness.

I think kindness, first of all, enables the kind of shared trust that is the emotional operating system for collaboration.

I get really excited about a particular form of collaboration open source, but collaboration itself requires us to trust each other, usually with pretty unformed ideas.

We're all going to mutually step into some piece of incompetence.

And if we feel like when we're showing up as incompetent, when we're blundering through our words, when we've got the brandest newest idea, maybe in a domain we don't understand well, are we going to get laughed at, right?

Or are we going to get smiled at?

And if you know folks are going to smile and help you move the idea forward from being a terrible idea being a good idea, then magic can happen.

So for me, there's this spiritual lineage of kindness that I admire.

And I think when we look at great leaders in history, at least the ones I pay attention to, typically reputed for kindness and the outcomes that they produce.

But just practiced in our daily life, if we can give each other just a little bit more grace, step away from our own reactions, then we might even end up being kind to ourselves.

And if we suffer less, we'll probably visit less suffering on others.

And that seems like the kind of world I'd like to live in.

There's a link to economics here as well, which is, the positive some games that I like to play that I think most people like to play.

Where it's not like a sports game of nonzero sum, where you're just going to step onto a field and one team is going to win and one team is going to lose and that's the end of it.

But to be able to say the more of us who play this particular game like love or an open source project or good stewardship of the earth, the more people who play it, actually, there's no upper limit to how awesome that game can be.

Unlike a zero sum game.

There's also negative sum games, which we don't like very much like pollution and global warming and the more people who played the worst thing is good.

So if we can find the shape of positive sum games, I think all of those have an immediate link to kindness.

Because if you can start to think about, what is kindness at scale?

It'd be really good outcomes for people's own sake times thousands, times hundreds of thousands, times millions.

Those start to look like markets in a way, right, those might be enabled by platforms of a particular kind or a style of play.

But you can end up with lots and lots of people in a positive sum game.

And that seems like a tremendous source of power and good outcomes for all of us.

So very philosophical, but I'm turning 50 this year, so hopefully you'll forgive me, my bent towards thinking about the world and our place in it.

Patrick: All these conversations, we typically start fairly technical and end fairly liberal arts, so it's not uncommon for the arc of the conversation.

Sam: That's such an interesting comment.

I think, what makes me really happy is that our industry is starting to balance its affection for science and for liberal arts.

And that to me is a great sign, not just in terms of inclusiveness and bringing people from many walks of life into this industry that I've spent my whole life in that's provided me with nonstop ability to satisfy curiosity and a good living to support my family.

But also, that we're going to come up with better solutions, more interesting shapes of worlds defined by software that are driven by people who can marry technology and the liberal arts as Steve Jobs said.

Patrick: One thing that we think a lot about at Orbit and are working towards all the time is changing the culture and the tooling around this space.

For me, it's an exercise in the sort of art and science of community and company building and strategy.

And ensuring that the tools we build are consistent with the values we hold and the culture we want to create.

So I think it's consistent with what you're describing there about the general shift in the industry.

Sam: I think both at the top level, Orbit.love is the URL, right?

That's a really bold choice, right?

It's not an obvious one, and there's a lot of risk that you've chosen to take on the chin and write directly into your implicit positioning.

That's pretty awesome.

Below, the design that you put into Orbit, both as the open source model and as the tool that automates interactions with it is really cool.

It puts the focus on the human being and doesn't reduce human beings into leads.

Patrick: Yes.

Sam: And I think that is just fantastic that it's an Orbit and it's not a funnel to a pipe.

I mean, bless selling bless sales process with bless sales tools, those have to run the way that they do.

If we come at the world from our point of view, our learn history as developers, literally every developer is a person unique and curious in particular ways and involved in different things.

And that being the basis of how Orbit works, I think is inspiring.

And effectively it's an opinionated point of view, and takes a lot of ways of looking at the problem off the table and actually implements a certain set of ethics and aesthetics right into the core of it.

And I'm inspired by it. And I hope that that's something that that keeps self projecting, self propelling and self correcting.

Because a tool that's that powerful could end up getting subordinated to serve other purposes, right.

Never cross that uncanny valley, right. But allow the culture to keep pulling you into always focusing on developer love. Right.

What is it that this human being is trying to get done and how can we help them?

Patrick: Yeah, yeah.

I appreciate you saying that, that's right on with kind of our vision for things and that the love.TLD was a deliberate signaling choice and it's worked.

But it's been fun as almost a verbal business card, like shoot me an email at patrick@orbit.love.

And then people are like, what, dot love, what does that mean?

And then it's a narrative look to describe our philosophy and our worldview. So it's been fun.

Sam: A bold choice and a tough one. Again, there's so much, I think, honor and generosity in being opinionated.

Because people can choose not to share your opinion and that's great.

But if you don't let them know what your opinion is, and it's kind of like an ongoing hoodwink, right, they already know what you stand for.

You can agree with anything.

So if you're just like, hey, here's what I do and here's what we're about, right?

We're available to meet.

Then the people who really do get excited by that show up and form your core community and nobody's confused.

Patrick: So speaking of love, the show is called Developer Love.

We talk about love a lot, obviously.

So one question I ask every guest is, what's one thing you're loving right now?

Sam: Well, I guess I'll pick three, if that's all right.

This is not going to be a super technical answer, but there may be some technology in it.

I love watching my wife's progression into becoming a fine artist and seeing how that's been accelerated by Zoom, of all things, because of the kinds of classes and experts that are available.

So it's some technical enablement there. I love seeing my daughter starting to get fascinated in data science.

She's graduating from UC Berkeley with a degree in environmental sciences in just a few months.

And as she looks at this, she looks at the tools of R and Python and how to interpret data and visualize it to help people move forward to take better care of the environment.

So it's fascinating to see technology written underneath there at that very ecological concern.

And I love what my son's doing.

He's a PhD student at UC San Diego, in nano engineering and try to solve very, very low level problems of emulating biological filtering of materials and being able to reproduce that in human made nano materials.

So a lot of that ends up dealing with computational nano chemistry, right, your ability to simulate a novel material 50, 100, 1,000 times in a virtual space before you actually go through all the process of like, oh, we're going to photolithography and we're going to lay down these nano sized holes.

And then we're going to grow nanotubes in them.

And then we're going to surround that with polymer.

It'd be nice, compared that it's got a pretty good chance of actually doing the right thing before you reduce it to practice and try to make it something in the real world.

So those technologies at the interface of all of these kinds of concerns.

Patrick: Well, Sam, you've been super generous with your time today.

What an amazing conversation. If people want to learn more about you and what you're working on online, where would you send them for more information?

Sam: That's a great question, you can come find me @sramji at Twitter, take a look at what we're doing at DataStax for sure.

There'll be, I think, a lot more interest in data on Kubernetes in the near future.

That's a place that's just totally fascinating to me.

And then one more that I point out, which is datameshlearning.github.com.

And there's a really amazingly cool community shaping up there.

It's inspired by Zhamak Dehghani, who's a technology director at ThoughtWorks.

And she's put together a bunch of the things that she's been learning about data architectures in the real world connecting the application plane with the analytics plane, and a community has kind of self generated on slack about, 800, 900 people already talking about architecture patterns.

How the old way is not working. What is a data mesh? So those are the shapes of my thoughts these days.

I haven't been publishing on blogs for a long time, so there's nothing novel there but I should get on it.

Patrick: Awesome. Sam, thank you so much for the time today. Really appreciate it.

Sam: Thank you, Patrick. Great to talk with you.