Fred Stevens-Smith: Hello, podcast listeners.
Today I'm joined with my friend James Lindenbaum.
James is the founder of Heavybit,
which is the thing that does this podcast.
Great description of Heavybit.
And also was one of the founders and CEO of Heroku,
right up until five minutes before
it got sold to Salesforce, as he just said.
So hello, James.
James Lindenbaum: Hello.
Fred: We had a little chitchat before,
and we kind of think we have some ideas
of what we want to talk about here.
You said that one of the real obsessions for you so far,
professionally speaking, has been quality.
Fred: So what do you mean by that?
Do you mean quality assurance, like RainforestQA
could help you with?
Or are you talking quality in very broad terms?
What does that mean for you?
James: In the broadest term, quality
in terms of the quality of what you produce,
the quality of your work.
So not so specific to QA.
QA is certainly a way to achieve some parts of that,
but I think that's one of those things that's personal.
What does quality mean to you?
I'm a very design-minded person, craft-minded person,
and so to me, quality has a lot to do with those ideas.
The question is always, how much is enough?
That's always the problem.
And how do you define quality? That's always a problem, too.
It's very hard to strive for quality. When you do, you often end up in this situation
where you're pushing somebody, saying we need more quality,
and they're saying, "What does that mean?" Sometimes it's definable,
but sometimes it's sort of ineffable.
It's like one of those things that you can feel.
It's kind of like that old Supreme Court quote,
where they were asked to define pornography.
It's like, I can't define it but I know it when I see it.
There's something certainly intuitive about that.
Fred: Are we thinking in terms
of the finish
on an office furnishing, for example?
Or are we talking about
how a product looks and feels?
What are the tangible examples that come to mind
when you think about this?
James: Just to get a little bit more specific,
a classic example is Apple products.
We can have a debate about today versus yesterday,
but let's say 10 years ago.
No question, Apple products were just of a caliber,
of a quality, that were above and beyond
anything else around.
It wasn't just one particular thing, it was everything.
It was the way it looked, it was the way it worked,
it was the way it felt.
A lot of times, you can measure quality most easily
in the emotions that occur in the people
who are exposed to that product.
Some products, you just get this sense
that a tremendous amount of craft and care
went into them. And other products you don't.
You can imagine a spectrum.
You can certainly imagine a product
where it's clear that a tremendous amount of care went in.
Every detail was considered.
And you can imagine the opposite end of the spectrum.
I won't name any names,
but you can think of products where, just, holy shit,
who said this was okay to ship?
What kind of person was okay
with putting their name on this?
And so if you can imagine that spectrum,
it's how far to the right,
how far to the quality of the spectrum do you want to go.
One of the really tricky things about that,
in terms of managing that with a product,
is that you can't define,
okay, we want 80% quality, 90% quality.
You can't really define that at the beginning
because it doesn't really mean anything.
What really happens is it's an accumulation
of decisions along the way.
You have all these little decisions constantly all the time,
and it's, is this good enough? Is this good enough,
can we move on, do we need to go further?
The problem is that you know you're okay with, you want great, you want good enough it doesn't have to be perfect,
but you want it to be pretty close.
And whatever your bar is, let's say it's 80% or 90%
or 98.6% or whatever,
the problem is that you don't know how to land there,
because you don't know how many more of these things
are going to come up.
You end up really needing to focus on 100%,
especially in the beginning of a project,
because you just don't know how many of these bullets
you have to spend.
When you get closer to the end of a product,
and you really feel like the polish is there,
you really feel like the caliber is where you want it to be,
you can start to let go of a few of those last things.
In the beginning you have to be really careful
about sticking to your guns.
It's this slippery slope to mediocrity,
always, that you're fighting against.
Fred: This brings up several questions for me, I guess.
One is, what are some examples, if you can share them,
of contentious decisions that you made, early on
probably in the life of Heroku or in the life of Heavybit,
where everyone was like, "What the fuck, James?
This is bullshit."
And you were like, "Quality, quality, quality."
Let's start with that.
James: Yeah, sure.
If you take a random sample of Heroku employees
I am sure you'll have no shortage of those stories.
Fred: James as a Service?
James: Yeah, exactly.
Photos of me standing over people's desk.
At Heroku in particular what we were trying to do
was simplify something that was complex.
And simplifying things is very, very hard.
Simplifying things really is a lot harder
than making things more complex.
To simplify something you have
to really, really understand it
and you have to often rearrange the entire solution,
rearrange the whole paradigm of what you're doing,
in order to just remove one part of the complexity.
And then you have to do that whole thing again
to remove another part.
You're trying to from 10 parts to,
I wanted to go from 10 parts to one.
Some people would struggle and struggle for months
to go from 10 parts to eight,
and then say, we've got to ship this thing.
We've spent months on it, it's much better than it was.
But to me, it doesn't matter how much time
you've spent on it.
What matters is whether you reach the bar
that you're trying to reach.
The Heroku command line interface
was sort of a classic example of this,
where we wanted to have
as few switches, commands as possible.
Fred: And the command line interface,
for the less technical people listening,
is basically the way for the nerds to interact with services
through that strange matrix-y looking window
of white text on a black background.
James: Of just text, right?
It's just text.
When we think about design, the user experience design
and developer experience design,
in the context of just text, just a command line interface--
Fred: Because that's still design, isn't it?
That's still the interface that they use
to interact with your product.
James: It's very much design.
Fred: And probably one of the only interfaces
for developers that they'll ever want to use.
James: That's right.
That's right, very few developers, especially at that time,
used the web interface.
They instead used the command line interface.
Fred: Did you build that first of all at Heroku,
or was that something that you guys added on
once you had the core functionality?
James: That's a complicated story.
We basically built them in parallel.
There was an earlier version of Heroku
that didn't really have that kind of command line access.
But then when we moved on to the second version of Heroku,
we built both in parallel.
We can talk more about that if you want,
but the concrete example of this
was that a huge amount of work went into trying to...
The classic example is the "create" command.
This is a way to create a new application
that lives in the cloud on the web, ready to go.
Prior to this tool, basically what you had to do
was 100 steps.
Anything that was less than 100 steps was an improvement,
but we wanted it to be one step.
Or possibly zero steps.
You had this command line tool where you typed "heroku"
and then something,
"heroku create" was the way to create a new application.
And then you could just push your code to it
and it would be up and running.
The issue is there are a lot of things that we need to know
at the time that you create the application,
like what's the name of the application,
where does it live, is there a domain name?
There's a whole bunch of configuration,
and the idea was to reduce and remove
as much of that as possible.
The issue is that it's not very straightforward.
When we first sat down to do it,
if you do what I always call the "naive implementation,"
this is the first thing that comes to mind
when you design a solution to a problem,
without having really considered all the details
and done that extra work to simplify it.
We had 10 switches.
"Heroku create" and then, blah, blah, blah, blah, blah.
Ten things that you had to specify.
So, then the question was, how do we get rid of these things?
There wasn't a clear answer.
Each one was different.
One of them, we needed to basically rebuild the entire way
that our back end worked,
so that a thing that we previously
required you to specify up front
you could specify later.
We had to rework the entire architecture
so there could be flexibility later.
Really, solely, to remove this one flag from the command line. And that met a lot of resistance
with the engineering team.
There's a lot of layers of infrastructure at Heroku.
So as you dive deeper into the stock,
you go from app developers to platform developers,
into pretty deep infrastructure and dev-ops folks.
It's a lot work to re-architect these things,
and in particular, they're responsible
for reliability and stability.
And so changing things, you have to have a really good reason.
This is a classic example of, is this a good reason?
Is it a good enough reason
just to remove one thing from the command line?
My argument was yes, because we had to get it down to none.
We literally had to get it down
to where you type, "heroku create."
Fred: And that's it.
James: That's it.
There was a huge amount of effort expended on this.
And then you have something else.
Another classic example is the naming scheme of these apps.
It turned out that having to name something
was actually a huge point of friction.
You wouldn't think that it is,
but it turned out in practice it was.
Because what we wanted was to get people very, very early.
They weren't even sure what they were building yet,
they just needed to deploy this piece of code
that they wrote.
When you stop and you're like,
hey, what's this thing called?
Suddenly it's this existential dilemma.
What am I really doing here?
What is the purpose of this thing?
What should it be called?
Does the name collide with this other thing?
And then you finally think of something,
and it's a global namespace
and somebody else already has that.
That was actually a meaningful problem.
Then the question was, okay, can we have a default?
Can we have sensible defaults?
That's another means of reductionism.
Again, naive implementation.
Think of some other thing you've done
that's probably like, "Untitled178394.
We just didn't like the feel of that,
because you're still trying to create something
that has a sense of value
and that you can remember and identify with,
has some personality.
How do you create that without requiring
the user to do anything?
We ended up coming up with this haiku theme,
where we basically wanted to have...
It was a pair of words, originally.
And so it would be like, "gentle river."
Or, "quiet samurai."
Fred: Every Heroku knowser use it--
James: That's right.
Fred: Every Heroku user knows it very well.
James: It became this famous thing.
It was sorta cutesy, and I'm glad we did it.
But the thing about it is that it was actually hard to do.
Because, again, the naive implementation of that
would have been two giant lists of words.
But then you end up with these combinations
that don't make sense or some of them are not appropriate,
or just weird.
I remember we had one that was like, "golden rain"
Certain combinations that didn't make sense,
that weren't good.
This ended up being a multi-week project
where we had these different sets of words
and there were algorithms
for which ones could go with the others
such that you would always end up with a haiku-esque thing,
made sense, and didn't have collisions.
It was this whole thing.
It was really ridiculed inside the company.
It was interesting.
Half of the company, maybe a third of the company,
was really stoked about it.
And two-thirds of the company were like, "What the fuck are these guys doing?
This thing has been ready to ship,
we worked our asses off on it.
What are they doing?"
Fred: Because floating over their shoulders
the whole time, conceptually, is this dumb hash,
which every other app ever does.
James: "It's just a fucking name, guys.
Let's wrap it up and let's ship this thing."
But there was a set of us
who just felt it was really, really important.
It wasn't that that by itself
was the critical thing, but again,
quality is this thing that's the aggregate, right?
And so all the different pieces of this
needed to be to a bar where,
in other words,
some people think of quality as an average.
I think of quality as the weakest link.
The lowest quality thing in the system
is the quality of the system.
Fred: Which is definitely true.
Look at the old,
when Microsoft was moving to Metro
and you would spend a very short amount of time
in this beautiful Metro tiled interface
that felt like 2020.
And then you get dropped into bloody Windows.
Fred: Oh, there it is, there's the "Start" bar.
James: You experience this in life.
You set up a fantastic vacation and you're going to Hawaii.
The whole thing is dialed in, you get on the plane,
you start clearing your head, your inbox is empty,
you spend those five hours
drifting into the zone of vacation,
relaxing away from work and hassle.
You land and it's all warm and pretty and nice
and there's flowers.
And then you go to the fucking Hertz rental car place.
And it's just like a clusterfuck for an hour.
You can't get out of there
and you've got to fill out these forms
with information that they already have.
Nothing aggravates an engineer more than that.
Yeah, I'm big on arrivals for that same reason.
The weakest link is the problem.
We pushed really hard for that,
and a lot of people had a problem with it.
But I think we were vindicated, ultimately,
at least in that case,
because it really affected the feel of the product
and the experience you had, especially as a new user.
You also have to remember, this is the way it's done now,
back then the idea of putting design and craft
and really caring about user experience,
for a highly technical
system engineering-style product, that was unusual.
That was a big part of why we wanted to do it,
because we just felt like everything else felt terrible.
I don't know.
There are countless examples of that sort of thing.
Fred: I remember very clearly that shift happening
and it definitely felt like it was driven by Apple, for me.
This notion that you would actually expect good design.
Good design wasn't just this fun thing that just happened,
good quality, as maybe you would say it.
But something that was put in place
from the very top level of the organization.
I guess that's something that's interesting to me. I would be interested to hear from you
to what extent you did that deliberately.
How does one create an organization
that is able to figure out
what that 90% or that 95% bar is,
beyond the feel? Because at some point
you're not in every single design meeting,
every single wire frame, every single discussion.
Lots of people in your organization
get to decide what is good enough.
How do you do that?
James: I will preface by saying, I don't know.
It's really hard and I will not claim
that we have mastered that.
It's probably one of the great mysteries for me.
But I think there are some things we've learned
along the way.
Personally. I do believe that design and quality
result from a sort of cohesive understanding
of the whole product.
The philosophy, the principles behind the product,
the way it's built, the way it's implemented,
the way it looks, the way it feels,
all those things are interrelated and are important.
Products that we all make are pretty complex.
It's difficult for one person
to have the entire product in their mind,
but it's equally difficult for a set of people
who, as a hive mind, have the whole product in their head.
It's difficult for them
to actually make great design and quality choices,
because really, each individual
is only looking at a piece of the puzzle.
My experience, both on the cases of good and bad examples,
and in my own work, is that it's very difficult
to achieve as a team.
All the cases of really excellent
work of the highest caliber,
it tends to be a design czar.
That design czar maybe could be two people or three people,
but it's usually one person.
It may be different people over time,
or different people on different projects,
but usually the case is that you really
have to have the entire world loaded in your head
in order to make the right decisions.
It's hard to share brains, right?
Fred: It's hard to delegate that.
James: That was me for a long time at Heroku.
That was tough because it's really more than a full-time job
and I had a couple other full-time jobs at Heroku.
And it caused problems.
I mean, in the early days, before we'd figured out
how to scale that a bit, I was a blocker on a lot of things.
To get James' approval was one of the steps
in the pipeline.
Eventually I was able to hand the baton off
to other people, Todd, Max,
a couple of different people at Heroku over the years
who did a great job of picking that up
and doing it their own way,
not my way, but doing it and doing it well.
So I think that's part of it,
is just recognizing that you have to have a design czar
and you have to give that person
enough responsibility and authority.
That person also has to be the kind of person
who can command respect.
Because I'm also, and this is a whole other discussion,
but I'm of the mindset that responsibility can't be given.
Responsibility and authority are connected,
and it can't be given so much as it has to be taken.
You also have to be the kind of person
who can command the respect for those decisions.
Part of that
is that you need to end up being right most of the time.
That's a big thing.
That's part of it.
Another part of it is it's a cultural thing.
Another part of it is how do you get your team
as it grows to actually have those values,
to actually care, to say, hey, what this company's about?
What this product is about, is this level of quality.
This idea of, let's ship it,
there's this implied objective there
that shipping more is better.
Shipping it sooner, shipping it faster, shipping more.
I'm a bit of a contrarian right now in Silicon Valley,
in that I don't think more is better or faster is better.
I am 100% a quality-over-quantity person. A lot of that is about trade-offs.
You can't just sit on your high horse and say, hey,
it's got to be really high quality and it's got to be fast
and it's got to be good and it's got to be cheap.
The classic trade-offs, right?
For me, you have to be realistic.
And so for me, what that means
is if you're going to have a really high bar for quality,
you have to be willing to give things up in order to get it.
Usually what those things are, are timelines.
You have to be willing to basically blow deadlines
or be unwilling to commit to them in the first place,
which is difficult to manage around.
You also have to be willing to be hard on people.
I would say that's the one that would, probably for me,
be a lifelong journey
to try to continue to be better and better at that.
I think, fundamentally, it's very frustrating
to work on something, to work hard on something
and to find out that it's not good enough.
Regardless of the means by which you find out,
it's just hard.
There's sort of the canonical Steve Jobs
bad actor version of that.
Fred: "This product sucks.
James: Yeah, "You suck.
I hate you, get out."
But you know, it's really about the work.
It's not about the person.
It's not, "You're terrible." It's, "This thing is a problem."
Fred: This thing that you made is terrible.
James: This thing that you made is terrible.
Fred: And a lot of people are not willing to do that.
It's much easier to say, oh, you spent 100 hours on this.
It's not quite how I would have done it.
That's the passive-aggressive way of saying
your work is terrible.
But it's good enough, fuck it.
How do you avoid that?
Especially when, and I'm thinking about this
through the ears or whatever
of somebody who's likely to be listening to this,
probably goning to be a founder,
thinking about starting something,
working in the core team of a late-stage technology company,
how do you balance that?
Like you said, it's a trade-off.
But how the hell do you balance that,
when you have your monthly growth rate
that you're thinking about and your investors
and all of these other resources in the company
are queued up behind.
How the hell do you do that?
James: It's a dynamic tension.
An important part of this is that you have to have,
there's some counterbalancing forces.
At Heroku the biggest thing was,
there were a number of good counterbalances,
but the most core was our founder partnership,
the three of us.
In particular, Adam is sort of a ruthless pragmatist.
He has a visceral desire to ship things
and get them off of his books
and mark them as done.
His visceral desire for that is as strong
as my visceral satisfaction
or sense of betrayal around quality.
If you can have two people
who counterbalance each other like that
and can find a way for that to be a productive tension
rather than just a destructive tension,
that was a really big part of what the magic was at Heroku.
Because, I would be saying, "No, we've got to go further.
No, we've got to go further. No, it's got to be better."
And Adam would be saying, "Got to ship it, it's good enough.
We've got to ship it, it's good enough."
Without me, he would ship a lot more stuff. But it wouldn't be nearly as good.
It wouldn't have been taken to the level
that he's capable of taking it.
And without him, I would just sit around polishing things
in a cave forever and never ship them.
Fred: The utopia of every designer.
James: That's right. Exactly.
Fred: And then you pull the curtain away and say,
look what I've polished over the last 10 years!
James: Over the last 10 years.
That's the problem, though, right?
You never really end up pulling the curtain away.
Or, by the time you do, it's not relevant anymore.
You need those counterbalancing forces.
On the second thing I said, in terms of riding people hard,
it helps to have counterbalancing forces there, too.
Orion, our other partner,
he's one of these big-fish storytellers, everything is an analogy, very creative, mad scientist.
He reads people very well and he was often able
to translate my feedback
or translate my objectives into the language of the person,
that mindset of the person who was working on it,
so that they really could grok it.
That's a skill that I have,
but I find that I can't simultaneously critique work
and be careful with people's feelings.
Fred: Yeah, you go into that hyper-objective mode.
You need help with that.
The third thing I'll say is around,
there's the cliched thing
around, "A players, get more A players," etc.
But in that vein,
when you have people on the team who are capable
of incredibly high caliber work,
it makes this a lot easier because you may have to be push a little bit to get it,
but everyone else sees that.
Instead of this, "You're asking for the impossible,
this can't be done, this is frustrating."
You see this other thing being shipped, and you're like, wow.
Okay, I can't really say that it's not possible.
These guys just did it, so I just need to get back to work.
Fred: The bar has been raised.
James: That's right.
Fred: And I also find that those kind of people,
they tend to be hungry for critical feedback.
Rather than rejecting it or being offended by it,
they're desperate for criticism in some ways.
The people who produce that kind of work,
it's because they've been pushing their own bar forever.
It's like anything.
It's like working out at the gym.
The heavier you lift, the heavier you can lift.
It's the same thing with the quality bar.
People who are really of that caliber,
they've been pushing themselves forever.
They won't feel satisfaction from their work
unless they have completed something to their quality bar.
And that quality bar is always going up.
The thing they ship today
has to be done to their satisfaction
to a level of quality that's higher
than they've ever done before. That keeps going up, every day, every project.
The only way you get there
is through true ruthless criticism, self-criticism.
You'll find that people who are of this quality mindset
are very self-critical.
You produce something and everyone in the world
says it's the best thing ever,
and they're like, yeah, I mean, it's okay.
But this sucks about it and this sucks about it. I would have rather done this thing.
I had to ship a little sooner than I wanted.
That's a really common pattern.
Like anything with a team,
the beginning really matters a lot,
those seeds of the culture, those seeds of the team.
You start with a person or two like that,
and it may go a little slower.
The things you produce, they just stink of this quality.
It's just wafting off of them
and it attracts other people like that.
Those kinds of people want to work in a place
that at its core respects that level of work.
Nobody who has that kind of bar wants to go work someplace
where they're told, "Yeah, yeah, we've got to ship it,
it's good enough, stop working on it."
They want to be at a place where somebody says, "You, your amazing work? It's not good enough."
Fred: I find myself making this mistake all the time,
where the trade-off, it seems to me
to some extent, is between authority, or "ownership"
is the trendy word,
against maybe this unified vision
or this central sense of quality.
As you can probably imagine,
and as I think probably most CEOs
of early-stage companies are,
that's pretty much me in our company.
Something that I see quite a lot
is having an internal dialogue of,
do I say to this team, "No, this is bullshit"? "This is nowhere near good enough.
There are these five usability edges
that I spot in five seconds of looking at this.
How can you even think about shipping this
to our customers who are paying us lots of money?"
I have to balance that against this notion
of, well, maybe the more I eat into their ownership
of that thing that they're trying to deliver,
the less motivated they become
and the more like, "Well, fuck this guy," that kind of thing.
It's less about being popular,
and I feel more about making sure
that you have a super motivated team.
Did you encounter that much,
or do you think it was just fundamentally
set up differently?
James: That's a constant battle,
and it gets worse as you grow,
because you have more and more surface area.
You have to have more teams.
You have more fragmentation of ownership,
which generally is good.
It allows you to decentralize decision-making,
allows you to move faster.
But it becomes very difficult to maintain that bar.
To me, also, and this is talking
more specifically about design
as one of the aspects of quality,
one of the most important aspects of design
Consistency, cohesion, continuity.
When you have different teams making decisions independently
about how a product looks or feels or works,
it's very difficult to have cohesion.
So even if you have three different teams who produced
if they're all slightly different
but they're all under the same product banner,
that still is bad design, in some ways.
What do you do about that?
Again, there isn't a right answer,
but I'll tell a few things that we've learned.
I think the model where you hand somebody total ownership,
you give them this whole pump-up speech
about total ownership over this area of the company,
"Do whatever you want."
And then they go to do something and you say,
"No, I forbid you from shipping this,"
that doesn't work very well.
Because it's a fundamental violation of the ownership.
It makes ownership feel like a bullshit thing.
However, you also can't just be fine with it
if you care about quality.
So to me, the balance that I've found works best
is that you give feedback.
It's not, "You can't ship this." It's, "I wouldn't ship it,
and here's why."
There's two parts to this, let me back up.
The first thing is, in my view, the way we always did it
was we wouldn't give ownership to a person
for a team or a part of a product
until they have already been through the crucible
of feeling like something was good enough,
being told it wasn't,
and then breaking through that barrier.
Just as a sort of tangent there,
we found at Heroku there was a really clear pattern
where people would come onboard
and we were very fortunate
in that we got going in a good mojo direction early.
I think part of that
was that we did really care about quality,
and that attracted really high-quality people.
We were going in a good direction
with talent coming on board
who were used to being the best on their team,
and they would come to Heroku and they would go through this
difficult emotional adjustment period
and they would come on board
and they would feel like they were the worst.
They would be constantly told, "Your stuff isn't good enough." And there would be this valley of despair.
What was interesting was there was a bifurcation there,
there was an inflection point
where some people would just eventually get frustrated
and leave or never overcome that hump.
But others, they'd bottom out
and then they would double down
and then they would come back
and they would finally get over that hump of quality.
Once they did, they would look at this thing
where two months ago they said,
"This cannot possibly be done any better,"
and we said, "You're wrong."
They didn't agree,
but then they went back to the drawing board
and eventually they built this thing
that was dramatically better.
And we said, "Oh my God, you did it, good job.
Let's ship it."
It was well-received, and then they felt
this really deep sense of satisfaction.
That has been true, I've found, in general.
People always feel this deep sense of satisfaction
when they ship something at a really high-quality bar
no matter how much they disagreed
with the process that led to it.
Anyway, there's this crucible you go through.
We would only put somebody in charge of something
who had successfully been through that crucible.
Now they were on the same page.
They cared, they knew what it took.
They pushed the rock up the hill.
They know how much energy it takes.
That's part of it, and I also,
I'm using the language of, "Put someone in charge."
But really, like I said, ownership has to be taken,
not so much given.
It's kind of the same thing
in that, in a culture that respects that kind of quality,
that kind of effort,
you really couldn't take ownership of something
unless you had achieved that,
because people just wouldn't follow you.
That's part of it.
You had the cultural background,
then the people who were running these things
are those kinds of people,
so that's a big part of it.
And then step two is the way you manage that
is you give them the real-deal feedback.
You leave it with them.
You can ship it.
You have the ship button, not me.
You have the ship button, you have the key.
I don't have a veto,
but I think your stuff is not good enough and here's why.
You can do whatever you want.
The power that you do retain
is that if they do ship things that shouldn't be shipped,
whether it's once or many times,
you have the power to replace them, basically.
You have the power to shift that ownership somewhere else.
In some organizations, that ownership will shift by itself
because people will look at the quality
of things being produced
and they will not want to follow that person.
Now, the organizations
that are a little bit more hierarchical
or more authority-driven,
that person will just not be
in charge of that project anymore.
I think that's sort of a balance.
The hard thing for you as a CEO or as a leader
is you have to be okay with seeing some things ship
that irk you.
Fred: Oh, yeah.
James: Now, you don't have to be okay with it forever,
but you have to be okay with it,
you have to be tolerant of some of it,
as somebody gets their feet under them,
learns. What you want is to see the trend
going in the right direction.
For me, as a perfectionist,
that's very, very, very difficult.
I want everything that ships to be perfect.
I see these couple of things and I'm like, ah.
But the truth is you're managing a lot of things.
There's a lot of surface area.
There's a lot of things that are shipping.
If things are generally of a really high quality
and things are trending in the right direction,
is the most important thing, it's worth that investment.
Fred: Super interesting.
The other thing that I think
would be great to dig into a bit
is the trade-offs that you mentioned.
And like you said, it always is a trade-off.
You said just before we started this,
that you have a framework of thinking about that,
and that's something that you're big on.
Can you expand a little bit?
James: Yeah, to me, everything is a trade-off.
Every decision that you make is a trade-off.
If you don't think of things as a trade-off,
then you don't really fully understand the decisions
that you're making.
When you choose one thing you're trading off something else
or maybe multiple things.
This is true in general.
With the quality discussion,
we talked about a couple of things that you're trading off,
and the question is, how far are you willing to go
in that direction?
For me, let's take quality over quantity,
which is sort of this mantra.
For me, it's much better to do fewer things
and do them well.
Everybody says that.
People kind of say that and get it,
but to really internalize that,
you have to think about, okay, imagine a product
that you're going to release.
You want it to be really good.
There's this minimum set of functionality
that obviously you have to have for the product to work.
How much of that are you willing to cut?
You've already cut from the scope
of all the cool things that were possible
down to what would be pretty good
down to the absolute bare minimum.
How much of that are you willing to cut,
10%, 50%, 85%?
Can you ship this thing that barely does anything at all,
that does maybe one thing, but it's perfect?
For me, I find that most people
have a really, really hard time accepting that.
To me, this is related to Paul Graham's
"Dig a deep but narrow hole,
rather than try to dig a wide hole."
If you drill deep but narrow,
you're going to have just a tiny thing
that's applicable to a tiny number of people,
but they are really going to see that you care.
They're going to feel the craft, they're going to care about it
and they're going to expect that whatever you do next
is going to be at that level.
It becomes part of your brand.
Richard Branson defines brand in a way that I really like,
which is effectively, to paraphrase,
"What you can expect from a company is its brand."
When you do things to that level of quality,
people expect that level of quality.
It's then very easy to roll out the next thing
and the next thing and the next thing.
And people will stick with you and they will celebrate
as you do those things.
Back to the Apple example, I remember,
I don't know, maybe it was in the '90s,
when they would roll out the new version of the desktop.
And Steve Jobs would spend like 10 minutes
on the design of the handle.
Fred: Yeah, yeah.
I miss those days.
James: And people loved it.
People loved it.
They were like, yes!
The handle is so much better now!
I remember these famous quotes from Bill Gates
and people on the other side of it,
who were like, "What the fuck?
It's a handle! Jesus!"
But that totally works.
Whereas if you deliver all the functionality
that people want but it's all kind of mediocre,
or even some of it's mediocre, that's your brand now.
Your brand is kind of mediocre.
You can add a bunch of stuff later
and you can maybe even fix the quality later,
although in reality that never happens, but that's it.
People are going lose it.
Everybody can think of that one product they got
that maybe was incredibly simple, did one thing.
Maybe it was a fucking carabiner, you know what I mean?
Maybe it's just one tool, one little piece of something,
but it was just perfect.
You told everybody about it.
People were like, "Which carabiner should I..."
You're like, "This one.
This is the one, it's got magnets.
I think that everything's like that.
How far are you willing to go?
There's an exercise we do often
where there's a couple different ways to do it. As a planning exercise it's fun
to make the list of things we're not doing.
What we used to do at Heroku was we couldn't leave the room
until we had listed 10 large things that we weren't going to do,
that were just unthinkable to not do.
Like, you had to do it.
Every customer wanted it.
People were complaining about it.
Everyone wanted to build it.
It was totally doable, it was super important, whatever.
If you're not super pained,
just super, deeply pained
by the things on the "we're-not-doing-it" list,
then you're not recognizing your trade-offs.
I'm also of the mindset,
the sect of people who believe that when you set goals,
that a goal isn't the goal
unless you're willing to trade things off for it.
You should be able name what those things are.
I think everything is a trade-off like that.
For the engineers in the audience,
you can go to the CAP theorem.
Or the equivalent of that
is the old, "Quality, speed, or cost:
Everything is a trade-off.
It's often a good exercise.
We actually just did
a little quarterly planning thing for Heavybit,
and we set some areas of values
that we wan to focus on.
We stated the value, but then we also went through
and stated what the trade-offs were.
If we want to achieve this value,
what are the things that we're not going to have?
Things that you want, but we're not going to have.
I think that's a really important way to think about things,
and it's an important tool.
It also forces everyone in the company,
when they have asks, they've got to pay.
Anybody, whether you're the CEO or anybody,
if you want something,
you have to pay for it with these trade-offs.
When I demand quality, I'm paying for it with budget,
with time, with feelings, hurt feelings.
So I think everything's a trade-off.
Fred: The final question that I'm still fascinated in
is something that seems to be happening,
and I think you and I both obviously agree on it,
and this is in some ways
part of the founding thesis of Heavybit,
is that business applications,
however we want to define those,
are becoming more design-conscious and less shit, basically.
The counterexample that you used earlier
was the thing that does everything
and all of the things are shit.
That's most business software.
Most of the stuff that we pay today
to do our fundamental business processes,
be it operations or be it development--shout-out to AWS, but guys,
your interface is outrageously horrible.
It seems like this is a wave
that's perhaps emanating from certain areas,
hopefully Heavybit, several other places as well.
How do you think about that?
If someone's listening who is like, "Yeah, James,
this is all great if you can afford to do it.
But I have 100k MRR,
I've got these users to please,
and I've got this roadmap to hit."
How do you think about the trade-off there
where you've already trained the customers,
or the customers already expect a basic level of shittiness?
To put it another way,
so many people have come in to the sales CRM space
and said, "We're like Salesforce but well-designed."
None of them are Salesforce.
That's something that feels like a hard argument
to counter for me.
Well, okay, there's a few things in there.
Firstly, I'd say that most of the people
who might be listening are probably starting companies
now or recently, and most of them
get a little nauseous when they hear the word "enterprise."
Because for most of us, that conjures
these pieces of software that you're talking about
that are just, you open up this piece of software
and it just feels like every customer request
that was ever made was said yes to.
Just anything that anybody ever asked for,
even if it was an edge case,
they said yes and they put it in there.
And so you just have this sprawling mayhem of chaos.
I'm going to go on a tangent here,
into one of my design principles.
I used to give talks on this
and it was a big thing we did at Heroku.
In addition to thinking everything's a trade-off,
related to that, I think everything's a spectrum.
I talk about almost everything as being a spectrum.
It's easier to understand things
if you think about the extreme ends of the spectrum.
James: One of the design spectrums, to me, is
we used to call it "machete design."
On one end of the spectrum is a machete
and on the other end of the spectrum is a Swiss Army knife. There are some really interesting things about this.
The Swiss Army knife
is the equivalent of enterprise software.
There's a lot of different things you might need to do.
Let's make sure you got a tool in there for everything.
One time somebody asked for a whittler.
So there's one in there.
There's one in there today.
There's a toothpick in there.
Fred: Whittler 2000.
James: The problem is you have all these tools in there,
but they're kind of mediocre.
The screwdriver in a Swiss Army knife
is kind of a terrible screwdriver.
There's no discoverability and there's no ability
to enhance these tools or to use them really well.
This is not the kind of tool that you carry around
like your precious prized katana that is your friend.
This is a tool that you throw in your pocket,
you know it's mediocre.
It's going to maybe come in handy sometime,
but if you're in a life-and-death situation,
you're going to be pretty bummed
that that's the tool that you have.
Versus the other extreme, the machete.
The thing about a machete, it's a single-purpose tool.
Sort of of the Unix philosophy: "small, sharp tools," right?
Tools that have single purposes
that can be strung together with other things.
A machete is very intuitive.
You don't need to use your manual.
You don't need to know what each tool is
or where to find it.
There's often a manual with a Swiss Army knife.
There's a thing that you open that tells you
what the tools are.
A machete, it's pretty straightforward.
There's a sharp side, there's a handle.
It's weighted in a way that you almost are forced
to swing it in a particular way.
The interesting thing about that, that's a little deeper,
is that your ability grows over time with a machete.
You can unlock features,
you can become an advanced user of a machete,
by becoming familiar with the tool.
As you become familiar with it,
because it's a simple tool and it's well-made,
it becomes an extension of your arm.
So maybe, you're starting out,
you're slashing brush or whatever.
But over time, you could use it to shave.
You could use it to make a sandwich.
You could use the tip as a screwdriver.
You could use it as a hammer.
As you become really intimately familiar with this tool,
and if it's well-made and robust,
you can use it for a lot of different things.
What's great about that is that it's discoverable.
This is directly related to discoverable interfaces.
You can unlock more functionality
as you get deeper and deeper into the product.
Whereas the Swiss Army knife,
you're stuck with this set
of mediocre things that you were given.
To me, the equivalent is,
I think of Microsoft Excel, is the classic thing in my head.
I think spreadsheets are one of the most important tools
that have been created in recent years.
But you open Microsoft Excel
and you've got the classic toolbar.
There's like 50 fucking buttons on there.
You don't know what half of them do.
The friction for becoming a user in the beginning
is incredibly high.
Because you pop in there
and before you can even enter a number,
it's like, pivot tables and just all this crazy shit.
It has that feel of, all the things you might want to do
are just stuck there in your face.
Anyway, that's sort of a design principle
that is, I think, related to what you're talking about.
Stepping adjacent to that,
there's this philosophy today,
very prevalent in Silicon Valley right now,
is the lean startup,
the iterative development.
Listening to the customers, getting feedback.
Small release cycles, fast release cycles.
Not that I disagree with any of those things,
and a lot of them are a business extension
of agile software development,
where we learned that waterfall is bad
and we basically can't foresee the future,
so we need to build things in small chunks
and see what happens.
But I think that maybe we've gone too far.
I'm a bit of a contrarian on this,
but I don't believe that user feedback is valuable
in a lot of cases.
I think that you want to observe users using your product,
but I think that the things they say they want,
I think there's little signal in that.
Users tend to ask for the thing
that's right in front of them,
they're one foot in front of the other.
Very, very iterative.
No user is ever going to ask you
for this fundamentally innovative thing.
No user's going to ask you to remove that feature entirely
or change the universe
such that that set of problems don't exist anymore.
Fred: Because they can't conceive of that world.
James: That's right, and it's your job
to conceive of that for them.
So if you get too caught up in this focus group cycle,
it's a real problem.
That's, in my mind,
part of what leads to what you're talking about,
which is this sense of, customers need these features
and the sales guys said that they can close this deal
if we add this thing.
Obviously that's a counterbalancing force,
like I talked about before.
You have external deadlines,
you have MRR targets, you have whatever.
But you can't lose track of the other side of that force,
which is that you have to fundamentally try
to simplify the problem.
You have to fundamentally try to build a machete
and not a Swiss Army knife. You have to have faith that when you do that,
you will have a following of customers
that is more valuable than the quantity of customers
that you may be able to get,
but you're going to have high churn on.
It's like these Kickstarters.
The thing with these Kickstarters,
they promise all these incredible features
that have not even been invented yet,
some of which may turn out to not even be possible.
They feel compelled to make these promises
so they can get enough sales.
I meet with these guys all the time,
and I just don't understand. If you sell fewer, if you sell 200 items,
it's like Paul Graham's "do things that don't scale."
Don't get hard tooling.
Don't go to China and figure out how to get good unit cost.
Just build them by hand.
They get really fucking expensive.
You have negative margins on them.
But get them to those 200 people.
Get that feedback.
But they always, instead, it's like, can we sell 5,000 units?
Could we sell 10,000 units?
Could we sell 100,000 units?
Great! We sold 100,000 units.
Now we can afford to spin up a whole supply chain.
And now it's fucking two years later
before we ship these things,
and as soon as we ship them we find out
that the design's wrong and we need to change it.
But it's impossible to get these guys
not to do it that way.
It's a very, very strong fear
that people won't buy something
that doesn't have these things that they want. I think the truth is that people respond to quality,
even when it's missing a bunch of things that they wanted.
If the things that are there are quality,
it's much easier to add things later
than to refine something, to simplify it,
to make it high-quality.
I don't know.
That doesn't really answer your question.
Fred: No, that's absolutely perfect,
and I can't think of a better place to end the interview.
Thank you very much, James.