Data is better than fuel. Fuel

just make something go faster.

Data creates this new asset

class of things that you can go

and create brand new things that

are even bigger than the thing

that where data came from in the

first place.

That's Ross Mason. He's the

founder of MuleSoft, a pioneer

in the API platform sector. Ross

is a giant in the data world. He

was among the first to recognize

the potential of big data in the

enterprise and wrote the first

line of code for MuleSoft in

2003. In 2017, he led the

company's successful IPO, and

the next year, he led MuleSoft

through its acquisition by

Salesforce for $6.5 billion.

Ross left the company in 2020

and went on to found Dig

Ventures, a VC firm that makes

early-stage investments in B2B

enterprise SaaS companies. Ross

also has tremendous insights on

entrepreneurship and how to

build companies that last. In

this episode, Ross talks about

all that and more, explaining

why connecting information is so

critical. Why CIOs are often

prime candidates to become CEOs,

and why it's important for

founders to find balance. This

is Daniel Saks, Co-CEO of

AppDirect, and it's time to

decode the power of APIs.

Welcome to "Decoding Digital," a

podcast for innovators looking

to thrive in the digital economy.

I'm your host, Daniel Saks, and

I'll sit down with other

founders, CEOs, and change-

makers to decode the trends that

are transforming the way we work.

Let's decode. Ross, great to be

connecting.

Hi, Dan. How are you?

Amazing, and you?

Very good. Thank you.

Great to be catching up with you.

Congrats on the MuleSoft

acquisition a few years ago by

Salesforce, and then congrats on

starting Dig Ventures. Tell us a

little bit about what you're

doing now with Dig.

While I was at MuleSoft, when

you build a company, you end up

stuck in this bubble that you

created that everything that you

interface with is things that

you've created or has come out

of your ideas. I started meeting

founders for coffee, because I

have coffee every morning, for

20, 30 minutes in San Francisco.

After a while, I met a lot of

founders. There were some I

really liked, and I started

investing. I

did that up until 2019, I

think, so six years. When I

moved to Europe, I thought I

really enjoy investing. I love

spending time with founders. I

love hearing about how people

are trying to solve new problems.

The problem landscape keeps

changing. It's so varied that

it's a super interesting time to

be in tech generally. I thought

I'd start a fund in Europe and

work with European founders,

bring some of the knowledge that

I had from the US over to Europe.

Dig stands for two things. One,

I've got to like what we invest

in. That's why it's called Dig.

If I don't dig it, then I don't

invest. You want to be talking

about the companies you invest

in at any social gathering or

anything like that. Sounds a

little bit weird saying that now

because no one's been in social

gatherings for a while. The

other thing I wanted to redefine

what value add was for

. All investors

say they value add, and the

reality is I think the

varies greatly

with the VCs and the seed funds.

What we've been doing this year

is thinking about how can we add

a lot more 10x or even 100x more

value than people are used to?

Let's rewind to the beginning. I

know that you were an IT

professional originally, which

led you to found MuleSoft. Can

you tell us some of that initial

pain point back in the day?

I don't know if people would

have called me a professional

back then. I was more of a

cowboy.

I like it.

I worked in software during Y2K,

that was a bust. I thought it

was going to be amazing. I

worked a lot in banking. Not

because that's where I wanted to

be, it's just where all the high-

paying jobs were. I started

realizing that, A, they're very

complicated. Loads of layers of

stuff all over the place. A lot

of manual, a lot of different

things for different needs.

Nothing's really connected.

Nothing really talks to each

other. I ended up gravitating

from apps to integration. My

first big integration project

was in London for a bank called

RaboBank. It was incredible

because we connected seven

systems, which is nothing. Seven

systems. There were about 12

different teams across all these

different systems who had

different agendas, and there was

a core integration team. We

created an architecture. It took

18 months. We did barely any

testing on it. We never tested

the disaster recovery thing that

we created for it. We went live,

and it kind of worked. You could

scale it. I don't know. For me,

it felt like it was a miss.

Actually, for everyone else

around us, they were hailing it

as this great new way of doing

things. It was called an ESB,

Enterprise Service architecture.

I just looked at it and I

thought if this is what people

expect, we can push the bar much

higher. That got me thinking

about, OK, what would I want to

do this differently as a

developer? That's where I

started.

Powerful. A few years back, you

wrote a book about the IT

professional and how you have to

break it. Can you tell us a

little bit about that?

The book was called "First,

Break I.T." It wasn't like a

Gene Kim book. I love Gene Kim.

He writes amazing books. He puts

a lot of thought into it. We

talked about collaborating a bit.

In the end, I realized this book

wasn't supposed to be a Gene Kim

book. It was supposed to be more

of a manual. Not a heavy manual.

A light manual to get,

especially IT people who are

managing, directors, or execs,

on the same page around some key

things, which were that the way

we deliver projects in IT is

fundamentally broken. Someone

like a Unilever will do 250 to

500 IT projects every year. They

reinvent the wheel every single

time, not because they're stupid,

or because the people there are

stupid, but just because it's

such a large organization.

There's no shared assets of any

description. About the only

thing shared is the vendors that

people use. IT has grown up,

basically standardizing on

vendors, but not standardizing

on approaches when it came to IT.

It's still very much like this.

Our big idea was IT is a cost

center. The budgets for IT go

down every year. Even though it

has all the digital assets,

which if you think about it,

after people, is the most

valuable asset. In a lot of

ways, people are temporary. They

don't stay in a company forever.

Your digital footprint is a

treasure trove of everything

that you've ever done with

everyone who's touched your

organization. Yet the people who

manage that and hold that,

treated it like a cost center.

Why is that? It's because they

don't get any reuse out of it.

There's no way of discovering

the information in a reusable

way that more than one party can

get access to. What we started

creating was a methodology for

unlocking more of these assets,

and a methodology for creating

projects around those assets so

you got more leverage as you

worked a lot. The book was

essentially just a tip to you

got to stop doing things the way

you're doing them. There's a

wholesale IT operating model

change. It's not massive, but

you have to create some new

teams, you have to stop doing

some bad habits. The book was

there to spark that conversation

and get people moving more that

direction.

I think it came out at a

relevant time where we're in the

midst of big digital

transformation. A lot of

companies and CIOs were

determining, do we go all in the

cloud? What does this consist of?

I think now, particularly this

year, everyone recognizes, from

the board to the C-suite down,

that there's a critical need to

operate digital first, and where

IT is not just supporting the

digital or technology function,

but supporting the business

processes and operations. Can

you tell me how the role of the

CIO needs to evolve to meet this

current demand?

That was one of my chapters.

I'll refresh it. Actually, it's

changed quite a lot. If you

subscribe to the idea that data

is an asset and it's like a

treasure trove. It hasn't yet

been sorted out and figured out

where the value is, but it's

there, then the role of the CIO

is to figure out the strategies

within the organization to make

it broadly available, and get

those assets to the front of the

business where they can be used

most effectively. To that

regard, you are starting to see

a shift where more CIOs are now

part of executive boards, real

boards of the company, which I

think is super important.

Otherwise, there's nobody there

speaking that language, helping

people understand why things

take so long and what kind of

changes need to happen in order

to speed things up. You're

starting to see a few people

transition from CIO to CEO. I

love that idea. That works if

the CIO is operationally-minded

and is thinking around running

their capabilities as a set of

operations as a service to the

business. It's very natural for

that CIO to move into the CEO

role. Interesting, what has to

happen between the IT and the

business is IT has to let go

this idea they've got to build

everything themselves. They do

that because they haven't put

the infrastructure in place to

allow other people to get

successful with the assets that

IT controls without making a

mess, or without creating

security breaches, etc. The

business also needs to have a

more directive strategy on how

they build their development and

data science teams in order to

take advantage of the assets

that are available to them in

the organization. It's also

very easy for the business to

say, "Oh, we need these things.

We haven't spec'd it out very

well, but we've thrown it over

the fence of IT, and they've

taken four months to go figure

it out. That back and forth in

the business creates conflict.

It makes the IT look bad, but in

reality, the business also needs

to get a better understanding of

their assets and what they need,

and how to specify them. Both

sides have to come together, but

it's definitely the CIO that

needs to move first.

When you see the role of the CIO

evolving, how do they

collaborate to think about the

business requirements and

benefit from the assets, which

is the data?

Back when I was active at

MuleSoft, it was mostly around

getting agreement between IT and

the business, and who owns what

piece of the puzzle. For example,

the IT organization would own

SAP absolutely. If you built

APIs on SAP, you'd also own

those because they're very tied

to the application. Those APIs,

to get a bit technical, aren't

very useful for people in the

business because they expose all

sorts of SAP junk that nobody

else understands unless you

understand SAP. We used to have

this API-led model which is

three layers of APIs. The first

layer is to decouple the backend

system with an API so you can

access it through newer

protocols to make it easier for

new tools and programming

languages to connect to it. The

layer above that is a set of

APIs that have been packaged up

within the context of a business

unit. Rather than exposing 500

fields in an SAP object, you may

only expose 15 to describe part

of the resource that it's

modeling, plus you might take a

few data pieces from other

locations. That resource becomes

the API that people will build

applications and work with. Not

revolutionary, but just being

systematic and thinking about

how to break systems down into

APIs so it can be more reusable

was a big thing. Now, IT can go

and do that, but what happens is

IT then says, "Well, I got to

run all this stuff. I can't

afford to run all this

infrastructure." The reality is

as soon as those APIs become

business context-centric, it's

better for the business to own

those APIs. They can have more

control over the life cycle on

the specializations on these

types of other things they bring

in. It's better for a business

unit to have more control over

their second layer APIs than the

first layer. There was always

this dance of helping the

business understand, "You've got

to fund people in here as well

to make this work," because they

like buying applications. The

reality is all in APIs is a

headless application, but it was

hard to get the business to

understand that. I think they're

starting to understand it a bit

better.

Let's decode this a little more.

For the listeners that don't

know what an API is, can you

explain what it is and how they

can get benefit from it?

Yes. An API is, essentially,

it's a contract between a

supplier that has a digital

asset or capability and a set of

consumers that want to use that

asset if it's a piece of data or

capability. The API is the

programming way of describing

how you connect to it, how you

query it, and what information

you'll get back from it, and

when things go wrong, and what

happens. It's very basic. It's

just a I/O mechanism for the

digital economy. The digital

economy is a sum of all these

interactions through APIs. An

API, honestly, can be protocol

agnostic. People get very around

the axle on it needs to be X or

Y. It doesn't matter. What does

matter is that it's described

well, that it covers the cases

so somebody can discover it and

use it. That it's put somewhere

where it can be discovered and

there's someone in the

organization or a group in the

organization that knows how to

help people when they get stuck.

You hear people say an API is a

product. The productization of

API isn't building the API. It's

putting all the infrastructure

around it to help people get

successful using it. One of

those is self-serve, but quite

often in the enterprise, self-

serve isn't that normal. You

also have to have these

enablement teams that work with

the APIs to help people get the

most out of what's available to

them.

Got it. Could you say it like, "

When you think of oil to drive

your car, you need

pipelines, you need gas stations,

you need infrastructure, and

then there's a connection point,"

and essentially, what data is is

oil and the pipelines are the

interfaces?

I knew you're going to go there.

I'm going to say, no, data is

nothing like oil.

Is it still valuable?

Well, oil is just a commodity,

and it goes up and down based on

demand. What makes data much

harder is it's different to

different people, and the shapes

of data is different in

different parts of the

organization. It's interesting

when you draw a map of what the

organization uses, and you've

got, say, 30 applications.

Everything, from Salesforce and

Slack -- well, that's Salesforce

now -- and everything else in

between, all of their apps,

they're apps. In fact, the way

their organization uses them and

how they come together on them

and what kind of information

they want from them is totally

different. All those different

pipelines to those apps are not

treated equally, and they're not

of the same value. What you have

to do is normalize access so the

data pumps. The first layer is

to make the data pumpable. The

layer above it is then to

specialize that data so people

can get the most value out of it.

Amazon had to go through this.

There's a very famous edict from

Bezos I used to like talking

about which was he told every

team that they had to interact

with every other team through

well-defined interfaces. They

couldn't use backdoors. They

couldn't do it any other way.

What they created was a very

loosely coupled environment of

software. It also created a lot

of repetition because they

didn't put any rules around. I

heard, reportedly, they had

about at least 60 different

objects to represent an invoice,

because invoice meant so many

different things for some of the

different parts of Amazon. But

in the midst of that chaos, what

they also have is all the

building blocks to go and build

everything. Data is better than

fuel. Fuel just makes something

go faster. Data creates this new

asset class of things that you

can go and create brand new

things that are even bigger than

the thing where the data came

from in the first place. It's

this very abstract but very

exciting element in our lives

today which is how well can you

find the right data sets, put

them together in interesting

ways, and, everything from the

way you store them, to the way

you present it, to the way you

report on it, changes the

outcome. It's almost like some

element we've never seen before.

It's much better than oil.

What are examples of businesses

who are effective in using APIs,

and what are examples of

businesses that maybe a struggle?

I would say a lot of businesses

at this stage are doing a

reasonable job, partly because

if you've gone to the cloud, the

way the cloud is connected is

through APIs. As soon as anyone

connects anything to anything

else in the cloud, it's using

APIs. Luckily, we went there by

default. Thank goodness. We went

there by default because if you

don't have an infrastructure,

there has to be another way to

get at the data other than

through the user interface.

Every cloud provider has APIs.

That's made things easy, and you

think, "OK, is there opportunity

to do more here?" Has it waned

or is it we hit the peak of what

APIs can do? What interests me,

what we haven't figured out how

to do yet, is stitch together

hundreds of APIs very easily.

MuleSoft allows you to do it,

but what we found even the

biggest implementations can get

really complicated because of

all the interactions and the way

it works. You can do it, but it

requires teams of people. The

other thing that still needs to

be solved in APIs, even as they

are today, is monetization.

We're horrible at...Especially

data APIs. The reason why

there's not loads of great data

APIs you can go and use is

partly to do with that shape

problem that one person wants

data a certain way, one wants it

somewhere else. It's hard to

capture that in the way APIs are

defined today. Also, they're

very, very hard to price. People

don't know what the data is

worth. They can't model it, so

they often don't make it

available. Then, finally, it's

trust, and I think this is the

big one a lot of people are

trying to solve right now is can

I share data with someone

without giving up the inherent

value of the data? By virtue of

me giving you my data, I never

get that back again. There's no

subscription model there except

for updates. Well, that might

not be interesting. If I've

given you five years' worth of

data, that might be enough for

you to go and build your own

thing and you'll never need me

again. The data monetization

piece is still super nascent.

Earlier in the conversation, you

mentioned the power of headless

experiences, but can you speak a

little bit to what you think the

future is for the way that

people interact with their

applications?

Yeah. The first thing is the way

I look at the industry, at least

I have done the last five years

but I think it is valid for the

next 20, the recipe for success

is connect, access, and then

enable. First, you have to be

able to connect to the things

that matter. That's pretty much

what we went for MuleSoft, just

being able to connect everything.

Amazingly, as big as we got and

as big as it's getting under

Salesforce, we barely scratch

the surface of what connectivity

means. To me, even with an API,

it's super hard to connect, so

you want things to sit on top of

APIs that have context, that

know how to connect better more

easily, and group things

together in a way that we can

understand as humans better.

Then, as machines, it's a whole

different game. We can talk

about that separately. The

future of apps as they are right

now, I've been investing in

certain apps the last three or

four years that are removing the

need to put data in, and they go

and discover the data, then

using a lot more ML to scoop

information up. Frankly, we've

been doing it with Gmail for

five or six years now where you

give certain things you trust

access to Gmail. That sucks it

up and discovers things. The

first thing that blew my mind

that did that was TripIt. I

don't know if you remember

TripIt, but I traveled a lot,

and this thing was sucking all

my travel itineraries and make

sense of what I was doing on my

next trip. That's a great early

example. It's a bit like what a

Zipcar was to Uber in some ways.

It was too early for its time.

They didn't develop it any

further than they got it. The

new interfaces will be much more

conversational, whether that be

voice, whether that be through

text, or whether it will be

based on the things we do.

Right now, phones have a ton of

understanding about what we do,

where we go, what we do, and yet

the best they can tell me is,

when I go get a coffee, that's

going to take me five minutes to

get home. It's like, "All right,

but I've got my calendar. I've

got all these other things." It

doesn't tell me, "Oh, you have a

podcast in 20 minutes and you're

15 minutes away from home. You

futz around with your setup for

the first 5 minutes, so you

should probably rush back." I

think the biggest thing missing

for me right now, and where I

get the most excited, is when

people start telling me about

how they use the context of

action and the context of

behavior in order to do

something new. It's been

difficult up till now because it

hasn't been accessible. Because

we've connected a lot more,

things become more accessible,

and then the enablement piece is

smart companies that go and

figure out how to join the dots

between all this noise. Pick out

the signal that matters to

create new valuable services and

products, or ways of doing

things, etc. That for me is

pretty exciting.

What's some parting wisdom for

IT professionals out there that

want to thrive in the next 10

years?

Oh, all right. Well, given how

many pitch decks I see that come

through the transom, many of

those people are going

off and starting to build their

own companies. I will talk to

the founder people first. I

spend a lot of my time speaking

to founders, and everyone I've

spoken to basically say this.

Looking after your mental health

as a founder is super important,

but that applies to anyone.

It's just that you put

unrealistic goals on your head,

and also investors do, etc.,

when you become a founder. You

basically say, "I want to go and

change the world," and then you

realize, "I'm just me and two

friends." That's really

stressful. Looking after

yourself a bit more than working

100 hours straight every week

for five years, it's a good way

to go and build a company, but

it's not the best way to live.

You end up sacrificing other

things. For professionals in

general, what's interesting in

the market right now, and where

I like to invest a lot, is in no-

code platforms. What's

interesting with the change

we're going through now is you

don't need to be able to code to

go and build a real product, and

that's pretty interesting.

We're going to see a different

breed of startups, side hustles,

everything else, where people

don't go for the big billion-

dollar unicorn, but they build

these tools that they can plug

into other ecosystems very

easily, and some will do well

with it and some have side

hustles. For an IT professional,

the thing to do to stay relevant

is to pick one or two niches

that you like and stay on top of

those versus trying to keep

abreast of everything that's

going on, because it's just so

broad that it's too hard to keep

track of everything. Then,

reading about funding

announcements on TechCrunch is

probably not the best use of

time either.

You made a good point around how

not everyone has to start to

create a billion-dollar company.

There was a perception in the

early days of tech that if you

started a tech company, it had

to be massive. To your point on

low-code/no-code and other basic

businesses that can be upstarts,

whether it's digital commerce

companies selling things online,

there's so much potential for

people around the world to start

a company. It'd be a great

lifestyle business, generate

cash flow, and then

balance your mental health as

well, and just living a great

life holistically, right?

Exactly. The cost of starting up

is super low. The building

blocks are essentially free. You

build on AWS or Azure, or Google

as a third option, but you don't

need to build a billion-dollar

business. We're told we have to

because that's what TechCrunch

reports on, and it's what

YCombinator is there for. I

also think there's another mode

which is, what about lifestyle

business? What about good cash-

flow-positive lifestyle business

and software that you serve a

set of clients well. Where does

that go? Does it have to be a

billion? Does it have to be

acquired or do you run it? Do

you keep the software going? Do

you expand? Is there cooperative

models? We're starting to get

to the point where there's

enough tools in place that we'll

see all sorts of things popping

up, trying out these new models.

That for me is pretty

interesting.

It's amazing. An everyday person

or someone who's not in tech can

benefit from APIs, and a result

could be that they can start a

cash flow generating business

using a low-code/no-code app and

be able to benefit from all the

history and technology and

foundation that's been built by

leaders like yourself.

Exactly. That's the whole point.

If we don't allow more people to

create in digital ways, then

it's a very interesting societal

question. We got rid of a lot of

the mom-and-pop shops, thanks to

the globalized supply chains,

etc., where you have these big

outlets. I'd love to see more of

that come back. We might start

to value that more post-COVID.

Another interesting mental

exercise, there's a friend of

mine I do it with every now and

then, which is, what does the

high street look like in 20

years? That's super interesting

because I don't see a need to

buy much from the high street,

but maybe there's other

experiences and other things

that I'd go there for. I go to

the high street for a social

thing, not to get things

purchased. I don't have an

answer for this, but we make a

lot of sense after about five

whiskeys, and the next morning,

we forget it all, but it's

interesting. We're living in a

world that will change pretty

dramatically, and not always for

the best either. We want to

think about what things can we

insert back into society that

brings us back together again

versus pull us apart.

I'd love to have you back on a

round two to talk about high

street, main street. The core of

why we started the business is

to help those businesses on main

street transition to digital,

and it does seem more likely

that a lot of the legacy

businesses that would have

existed on main street may

struggle to transform digital.

However, there'll be a whole new

breed of digital upstarts, like

you're saying, that will be able

to thrive, generate cash flow,

and provide a great income

stream for their families, and

essentially live a happy life.

Would really love to

have you in another conversation

to decode high street.

All right. That'd be great. I'd

love that actually.

Amazing. Ross, thanks so much

for joining us. This was great

and take care.

Great. Thank you.

On the next episode of Decoding

Digital.

Occasionally, you can't copy

something that hasn't been

invented yet. What I want the

world to understand is that all

of us, if we're ready to do that

little bit of innovation the two

or three times in our life when

it matters, the world's going to

be a better place.

Co-founder and Director of

Square, Jim McKelvey. Thanks

for listening to Decoding

Digital. Make sure you never

miss an episode by subscribing

to the show in your favorite

podcast player. To learn more,

visit decodingdigital.com. Until