Jason Crawford

Saw this in my Twitter feed today (retweeted by @andrew_chen):

sachinrekhi Funny thing about Chrome OS is that it’s analogous to going back to the days of Terminals where data & computation was server side

I don’t know a lot about the history of computing, but haven’t there been major shifts back and forth over the decades?  The terminology I’ve heard includes “dumb terminal” vs. “smart terminal”, “thin client” vs. “thick client”, and “centralized” vs. “decentralized” computing.  There’s always been a major question of how much computation and data should be at the endpoints, and how much in relatively centralized resources, whether it’s mainframes and their terminals, Web apps and browsers, or mobile apps running on smartphones.

I’d guess such shifts are natural, depending on the availability and cost of bandwidth, storage, memory, and CPU.  Will they continue?  The Web enables a hybrid approach that seems to provide the best of both worlds: apps and data live in the cloud, but some code (JavaScript, Flash) is downloaded and run by the endpoints.  Hosting apps centrally affords many advantages, especially the ability to deploy software updates almost instantly, by a process that is usually effortless or even invisible to the user.  Downloading some code (especially UI code) allows maximum performance and responsiveness, but—this is critical—that code, too, can be updated instantly and seamlessly.  (Projects like Google Gears are even providing offline access without sacrificing this essential advantage.  I love offline access in Gmail; for me, it was the biggest feature Gmail lacked compared to Outlook.  Most services, such as Dropbox and Evernote, still achieve offline access using desktop clients, but I suspect this will change eventually.)

I don’t think this hybrid approach could have been done from the first days of computing; it had to wait for a certain level of bandwidth, memory, and CPU (not to mention advances in programming languages and software design—could we have had Web apps running JavaScript before OO design?)  The mobile world is still a bit before this point:  Web apps work on mobile, but they’re usually too slow and unresponsive, so most apps are native.  (This is a major disadvantage for mobile apps; no mobile app can fully practice continuous deployment, and the iPhone App Store approval process greatly exacerbates the problem, as Paul Graham points out in a recent essay.)  But in maybe five or ten years, mobile devices and networks will be powerful enough to just run Web apps, and software will shift again.

Does anyone know enough about the history of computing to provide some perspective here?

On a related note, read Naval of Venture Hacks on why you will eventually dump your laptop and just use your smartphone.

UPDATE: See also the Jargon File on “wheel of reincarnation” (thanks @mjgardner).

Recently I’ve started using two iPhone apps that sync data with servers: Evernote and Kindle. Evernote syncs the notes; Kindle syncs your last-page-read, so you can go back and forth between devices (Kindle, iPhone, desktop, etc.) without having to find your place again each time.

Unfortunately, apps can only sync when they’re running, and they can’t run in the background. This is a problem, because it’s easy to quit an app before it has a chance to sync completely—for instance, if I’m jotting down quick notes in a meeting and quickly close Evernote, or if I’m reading a Kindle book on the subway without connectivity.

Apple provided push notifications as a relief valve for problems caused by lack of multitasking.  Will they provide a special sync API next?  Or will this problem go unsolved until the devices become powerful enough that Apple feels comfortable allowing background apps?

The top thing I’ve learned about management is a rule I call “query for judgment.”

Simply put, it’s this: by default, always ask your reports for their judgment before giving your own.  Ask their proposals on how to solve a problem.  Ask their ideas for products or features.  Ask their opinion on prioritization.  Ask their thoughts on risks.

Compare these approaches:

• “Team, the new ad campaign is doing really poorly.  We need to completely change the messaging on the landing page—focus on the cost savings instead of the new features. Make that your top priority.”
• “Team, the new ad campaign is doing really poorly.  I think we need to make major changes on the landing page.  What changes should we make?”
• “Team, the new ad campaign is doing really poorly.  How can we fix it?”
• “Team, the new ad campaign is converting at 0.2%.  How does that compare to our expectations? … OK, well, how can we fix it?”
• “Hey, how’s the new ad campaign doing? … Oh. How does that compare to our expectations? … I agree. How can we fix it? … Change the landing page? That makes sense, what should we change?  …  That sounds good.  Where does this fall on your priority list?  …  Great, sync up with me tomorrow and let me know how it’s going.”

The top advantages of this, as opposed to giving your thoughts first:

• You learn about your reports. You learn how good their judgment is, how creative they are, how savvy.  You learn what they’re good at and what they’re not.  You learn what kinds of issues they’re sensitive to.  One of your top jobs as a manager is to know your reports; constantly sampling their judgment is a way to learn about them.
• You show your respect for them. You, the boss, are asking them what to do.  You’re showing that you believe they can operate at a higher level and expect them to do so.
• They get appreciation for good judgment. If you agree and have nothing to add, all you have to say is “I agree, go for it.”  As an employee, hearing that feels great!  Or if you think they’re 90% right, you only have to make a minor course correction.
• They might even have a better idea than you. If you’ve hired high-judgment people, this happens sometimes.  But if you always tell your idea first, you might never find out.  They might not be the type to speak up, or they might be afraid of contradicting you, or they might just never get their creative engine going without that spark.
• Conversely, they get clear feedback when they’re wrong. If an employee has an awful idea or bad judgment, they’ll find out, because you’ll hear that idea and explain why it’s wrong.  The feedback loop you enable when you query for judgment works both ways, positive and negative.
• If you disagree with them, you know how far you need to bring them, and in what ways.  You might expect to spend your time convincing your engineers that they need to double the performance of your web site, when what you’re actually going to have to spend your time on is explaining why the site navigation needs an overhaul.  You won’t know until you hear their thoughts.
• Regardless, they always feel heard. They might complain about your judgment, but they can never claim that they don’t get a chance to voice their own.
• You become a clock builder, not a time teller (in the terminology of Built to Last). You aren’t just getting things done, you’re investing in your people and building bench strength.  You’re showing that you expect them to be autonomous, and you’re teaching them that you aren’t going to supply all the answers.

Towards the end of my time at Amazon, I was trying to wean my engineers off of my help.  I started having one-on-ones with them that went like this: “So, how’s your project going? … OK, how do you feel about that progress? … OK. What do you think are the next steps? … Sounds good. Which of those is most important? … I agree. What are the top risks this is facing right now? … Good, so, what can we do about them? … Great, thanks.”  I gave no input except to ask the right questions; I let them come up with all the answers.

“Query for judgment” is related to “seek first to understand” (from Seven Habits), but it’s doubly important for managers, especially since it doesn’t come naturally.  As a manager, you probably got your role by having high judgment, so you’re used to having the best ideas.  As a leader, you may feel that you’re supposed to have the best ideas and that your role is to give them to people.  But for all the reasons above, you should query for judgment first.

I just placed a needless call to tech support.

I was trying to get Internet access through one of those services that captures you using a proxy and makes you log in.  In this case, you could enter a username and password, or just a prepaid code; I had a code.  When I entered it, I got:

Your username is invalid.

I was confused: I hadn’t entered a username, didn’t have one as far as I knew, and didn’t think I needed one if I had the code instead.  Maybe I needed to register some sort of account?  But the only way to register an account was to pay, and I was supposed to get this free using the code.

After a few minutes of exploring options, I called tech support.  It was only while waiting on hold that it occurred to me to check whether I had entered the code correctly.

I hadn’t.  I had transposed two digits.  Just as a support person was answering, I got in. “Nevermind,” I said sheepishly.

My error was simple: easy to make, easy to check for, easy to correct.  Yet I spent minutes trying to diagnose it and wasted a minute or two of some support person’s time, because the error message was misleading.  It told me my username was invalid, when I didn’t have a username and in fact the code was wrong.  If it had told me the actual error, I would have found and fixed the problem immediately.  In fact, in this case, if it had even given me a generic error message (“Sorry, an error occurred”) I would have guessed the error quickly.

Error messages are important.  They are often overlooked as a corner case—after all, the software isn’t supposed to have errors.  But they happen anyway, because of inadvertent bugs, temporary failures in external systems, or—as in this case—user error.

Error messages are part of your user interface, and need to treated as such.  They need to be designed.

Here’s another example:  Suppose your application uses the Twitter API to post tweets on behalf of your users.  Something goes wrong while tweeting.  If you give a generic error message such as “Error posting to Twitter”, the user is left wondering:  Was it just a fluke?  Is Twitter down?  Did I enter the wrong password for my Twitter account?  Is this app just not working?

These cases require different actions of the user: try again immediately; try again later; correct the password; contact tech support.  A generic error message gives no guidance.  Worse, claiming the error is one thing when it’s actually another will send the user down the wrong path—as happened to me with the Internet access.

In fact, one good test of an error message is:  Does it let the user decide what to do next?  Here’s an example that fails that test in a different way.  Windows, upon waking up from hibernation, can give an error like this:

The last attempt to restart the system from its previous location
failed. Attempt to restart again?

      Delete restoration data and proceed to system boot menu
      Continue with system restart

A friend of mine got this tonight and was not only confused, but worried.  What does it mean to restart from the system’s previous “location”?  More importantly, what exactly is this “restoration data”?  Without knowing that, the prospect of deleting it is frightening—for all the user knows, it might mean “wipe my system clean and lose all my files.”  My friend called two people for help before making any move at all.

It turns out this message basically means: “Windows tried to hibernate, but hit a problem restoring your memory snapshot. Do you want to try again, or should we just dump the snapshot and do a normal boot?” Dumping the snapshot is no big deal (assuming you saved your work before hibernating).  But the user doesn’t know that, and is paralyzed as a result.  Explaining the error and the options clearly would have let the user take action confidently without consulting two friends and eleven Windows user forums.

Error messages are part of your UI, and should follow general UI design principles. They should direct the user what to do next, or present clear, meaningful choices and enough context to make them.  The next time you do a UI, include error messages in your design.

I stumbled onto a negotiating tactic at age 18, while renting an apartment.

I was looking for a sublet during a summer internship at Caltech.  A student offered to let me take over his lease on an apartment a few miles away, and we were discussing it.  At the time, I was slow to make any decision I saw as important, and this was one of them.  So when he made the offer, I couldn’t make up my mind. The ensuing conversation went something like this:

Me [thinking about it]: Hmmmm. [A pause.]

Him: If you take it, I’ll help you move in.

Me [frowning thoughtfully]: Hmmmmmm. [Another pause.]

Him: OK, I’ll knock $100 off the rent.

Me [eyebrows raised to indicate that this was attractive]: Hmmmmmmmm. [Another pause.]

Him: … and I’ll let you borrow my bike for the summer.

At some point, I realized: I’m winning the negotiation just by stalling. I even held out a little longer just to see what else he would offer me.

He was nervous about the negotiation, anxious to close the deal.  His response was to sweeten the deal for me.  If he had known me better, he might have just waited to let me mull it over.

I don’t recommend this negotiating tactic in general.  (For a good strategic approach to negotiation, see the “principled negotiation” framework explained by Fisher and Ury in Getting to Yes.)  The lesson here is from the other side:  Know when to keep your mouth shut.  When you’re nervous, it’s tempting to fill the void by talking.  This is especially true right after saying something you were expecting a negative reaction to: “We’ve decided not to give you a job offer.” “I’m not giving you a raise this year.”

It’s better to just deliver the message, and then stop.  There might be silence for a few moments while the person thinks and reacts; let it be.  They’ll answer soon enough, and your tension will be diffused.

Chris Dixon wrote last week about the trust- and relationship-centric approach of startups vs. the “legalistic, transactional mindset” in a post titled “Twelve Months Notice”:

For example, let’s suppose you are a two years out of college and have a job at a startup.  You like your job but decide you want to go to graduate school.   The big company legalistic types will tell you to secretly send in your applications, and, if you get accepted and decide to attend, give your boss two weeks notice.

What you should instead do is talk to your boss as soon as you are seriously considering graduate school.  Give them twelve months notice.  Any good startup manager won’t fire you, and in fact will go out of her way to help you get into school and get a good job afterwards.  They will appreciate your honesty and the fact that you gave them plenty of time to find a replacement.

I agree.  I have quit three jobs: D. E. Shaw, Amazon, and most recently Pelago.  Each time, I gave as much notice as possible, usually months.  I told my manager (and sometimes his manager) as soon as I was seriously considering leaving.  To the great credit of all three places (and all of those managers), they were all supportive.  In the same spirit, I’ve always tried to remain a 100% dedicated employee to the very end.

If you’re a productive employee, no manager worthy of his role will hasten your departure.  They’ll want to hang on to you as long as possible.  (You might even find yourself negotiating for how soon you can leave.)  The only motive I can imagine for firing someone in that situation is spite—a motive so petty I’d hate to think I had ever worked for such a person.

Chris stresses that the startup world is dominated by an approach that “relies on trust, verbal agreements, reputation and norms.”  I agree, but many bigger or more established companies take the same approach.  It’s just a matter of taking a broad perspective and a long-term view of what leads to success and reward.  What goes around, comes around—or to put it positively, you get what you give.

The Incredibles is one of my favorite movies, and its director, Brad Bird, is intelligent and articulate.  So a few years ago I watched The Incredibles with director’s commentary. I remember two insightful things Bird said that were relevant to startups.

One of them is a story he repeated in an interview with the Museum of the Moving Image:

It seemed like for years I was throwing a thousand decisions a day into this bottomless pit, and I’d go, “Is anything going to happen with these constant judgments I’m making?” And, “Oh, yeah, we got them, we got them.” So it’s another day, another thousand decisions into the pit—where you’d never hear the splash, either—and it’s just (makes a wind sound). (Laughter) And you go, “Is this movie getting done? I don’t seem to see any…” “Oh, yeah, we got it, it’s getting done.” And, seemingly, nothing happens. Then, suddenly, you get these images, and they’re more complete than you could ever imagine them, and all the lighting is there, and all the details are there. It seems like it was made overnight.

Throwing a thousand decisions a day into a bottomless pit, only to see it all come together much later.  Software can be like that.  Getting more visibility is part of the motivation for Agile development and minimum viable product.

But you can still get that bottomless-pit feeling working towards any large-scale, long-term goal—such as building a product or a company from scratch.  You have this grand vision and it won’t be fully realized for years, no matter how many milestones you hit along the way.  Every day you do small tasks—going to meetings, writing emails, reviewing specs and mockups—and you make decisions all the time, a thousand decisions a day on all sorts of little details.  It’s hard to hold on to the long-term vision and to believe that the mundane tasks you’re doing day to day are adding up to it.

The best antidote I’ve found is to set goals—a hierarchy of goals.  Then I can see how the day’s tasks add up to goals for the week, the week’s goals add up to the month’s, the month’s to the quarter’s, and the quarter’s to the year’s.

Have you experienced the bottomless-pit feeling?  What do you do about it?

(PS: If you liked The Incredibles, check out one of Bird’s earlier, lesser known films, The Iron Giant.)

I have a friend who is a successful real estate developer in VA.  He’s been in the business since probably before I was born.  Recently he gave me some advice about business, a piece of which really stuck with me:  When you’re trying to do a deal, it’s better to get a “no” than a “maybe.”

A “no” is straightforward and frank.  If you’re lucky, it comes with reasons.  That gives you something to work with.  Maybe you won’t get the deal, but at least you’re having a conversation.

“Maybe” could be legitimate, but it’s also what you get when someone just doesn’t want to talk to you.  If they don’t want to explain, negotiate, or even give you feedback, they’ll tell you “maybe.”  Unless you get clear reasons for the maybe and some way to turn it into a “yes” (or even a “no”), you’re going nowhere.

This rings true for me, especially given how VCs say “no”.

Friends have wondered why I’m moving to San Francisco, especially since they know me as a New Yorker at heart.  I researched a handful of cities extensively before deciding, so my choice is based on a lot of data.  For instance, San Francisco has the highest population density of any large city other than NYC.  It’s also home to some of the most educated and high-income people in the country, 2 of the top 25 universities, and arguably one of the top 10 symphony orchestras.

But the biggest factors are qualitative.  First, the Bay Area is the best place in the world to do a tech startup. I say this unequivocally because it is undisputed.  People don’t debate: “Where is the best place to do a startup?”  They debate: “Are you crazy if you don’t do your startup in the Bay Area?”  Paul Graham, for one, says simply that startups would do better if they moved to Silicon Valley.

For the record, I agree with folks like Fred Wilson, who derides the startup hotbed inferiority complex and says: “Not every great tech company comes out of Silicon Valley and you don’t have to be there to be a successful entrepreneur…. You can build a great startup in any of the dozen to two dozen startup hotbeds around the world.”  (So Fred, please don’t call me a Silicon Valley bigot.)

Second, San Francisco is the only US city other than New York that has the properties of a black hole, by which I mean: People get sucked in, and you can’t get them out.  (Ask any recruiter in Seattle.)  And SF has one of the highest costs of living in the US, which means people are paying a premium to be there and still won’t leave.  Moreover, people in a black-hole city seem to be so excited by what’s happening there that they don’t even think or talk about anything outside—as if they are beneath some event horizon beyond which even light cannot escape.

Economics says that when there’s a gravity well that deep, there’s a reason.  I’ve lived in New York, and I know the reason there.  I want to learn the reason for SF.

In the end, though, what convinced me is that I’m going to be a first-time entrepreneur, and I think I will learn faster in Silicon Valley than anywhere else—through exposure to peers, mentors, and the general milieu.  There’s nothing more valuable to me, since I have a lot to learn.

In 49 BC, Julius Caesar—not yet emperor—was in command of an army in Gaul, preparing to march on Rome and seize power.  At the time, part of the border between Gaul and Italy proper was a river known as the Rubicon.  To protect the Republic, Roman law prohibited any army from entering Italy; by crossing the Rubicon, Caesar was making war inevitable.  It is said that as he crossed, he declared: Alea iacta est! “The die is cast!”  To this day, “crossing the Rubicon” refers to committing oneself irrevocably to a bold and risky course of action.

I am now crossing my own personal Rubicon.  In the next few weeks I am quitting my job at Pelago and moving to the Bay Area.  In the next few months I will be doing my own startup.

In making this leap, I am leaving behind a secure, comfortable life.  I’m changing a lot of things at once.  I’m taking on a bigger challenge than I’ve ever known, and more personal risk.  At times I’ve asked myself, “What am I doing?”  But I know this is exactly what I want to do.  Starting my own company has been my primary goal in life since high school.  All of my career has been a training ground or springboard towards this end.

If I succeed, it will be the most rewarding thing I have ever done.  If I fail—at least I will own the failure.  In any case, it will be the adventure of a lifetime.

Alea iacta est!