Jason Crawford

Some managers—the pointy-haired boss variety—think their job is to tell people what to do.  They focus on communicating solutions.  If the website is slow, they tell their people to optimize the database queries.  (Hopefully they at least focus on getting alignment with their reports, instead of managing by fiat.)

Better managers focus on communicating problems.  When they have alignment on problems, they query for judgment about the solutions.  They just point out that the website is slow, and they ask their reports how best to fix it.

I think the best managers, the true leaders, focus at a higher level still—on communicating values. When they have alignment on values, their employees are able to identify the problems themselves, and are motivated to solve them.  They communicate ahead of time that a good user experience is important and that performance is part of that.  When the site is slow, their people notice it themselves and know how to prioritize.

Like many of the best management and leadership techniques, communicating values isn’t something you can do at the last minute.  It’s a long, slow process.  You have to start it early and work on it consistently and patiently over time.  It’s not a way to fight a fire.  But it is a way to grow a garden.

When I have 10 minutes or less, I can inform or entertain myself by checking email or Twitter on my iPhone.

When I have 90 minutes and some table space—and preferably wi-fi—I can be productive on my laptop.

Since getting a Kindle a month ago, I’ve found that it’s perfect for that spot in between, when I have around 45 minutes, maybe not much space, maybe no wi-fi—for example, getting lunch by myself in a small cafe. That’s too long to productively do email on the iPhone, but not ideal for working on the laptop, either.

When tablets arrive, what sweet spots will they fill? Michael Arrington wanted one to surf the web lounging on his couch. Web access in small cafes as well? Reading or even writing on buses and trains? It’s possible to use a laptop there, but not always convenient. Presentations and other business meetings in restaurants? I’ve been in meetings recently where someone pulled out hardcopies of mockups or spreadsheets—we both had our laptops, but there was no room for them, and the upright screen on a laptop isn’t ideal for sharing and collaboration across a table.

The top use case for tablets may surprise everyone. Regardless, the winners there—as with any new platform or medium—will not be those who simply bring old experiences to a new space, but those who embrace the differences of the new space and create new experiences there that don’t work elsewhere.

Google: “The information is out there, we just have to crawl it and index it.”

Amazon: “The data lies in user behavior, we just have to apply the right machine-learning technique.”

Facebook: “If we make it fun, users will enter the data themselves.”

Twitter: “If we build an API, third parties will solve the problem and all the data will just flow through our system.”

How do you get your data?

(PS: People who don’t have an answer to this question yet: most of the social-recommendations apps, all the semantic web guys)

A few things I’ve read lately state or imply that developer experience is what drives platforms.  Paul Graham says: “If programmers used some other device for mobile web access, they’d start to develop apps for that instead [of iPhone].”  Dharmesh Shah says explicitly: “What drives these technology cycles [thin client, thick client] as much as user experience is the developer experience.”

I disagree.  I think user experience drives platforms.

A software platform is a bipartite network of developers and users, with classic bipartite network effects:  Developers want their apps to have the most users possible; users want the platform with the most/best apps.  In many (all?) such networks, one side dominates and controls the network; the other side follows them and often pays all the costs of the matchmaking.  Sellers go where the buyers are.  Companies spend tens of thousands of dollars per hire to get the best candidates.  Men go to the bar or dating site with the most interesting women.

I’m not sure what determines which side of a network will dominate.  It doesn’t seem to be based on which direction the money is flowing (or whether there’s money involved at all).  I suspect it’s based on how many matches each side is looking to make, and how fungible they consider the other side to be.  In commerce, in particular, each buyer is looking to buy one or maybe two cars, let’s say, and the decision matters a lot to him, whereas each dealer is looking to sell many cars, and doesn’t care so much whom he sells to—all dollars are the same.

In software, I think users dominate the network.  Software is primarily an industry; every company has to calculate the ROI of development effort against each platform, and will ultimately choose the platform that gives them the most customers or users.  Even hobbyists are motivated by attention and appreciation; they may not care about making money, but they want their software to be used and liked.  Thus the same bipartite network effects are in play.  (Those who are creating software purely as a personal project are a small minority, isolated by definition, and don’t drive the market.)

So users will go to the platform that has the best user experience, and developers will follow.  Otherwise, why have so many applications been written for Windows?  Most software engineers prefer the Unix development environment.  But Unix, written by and for software professionals, dominates only in the server market, where the users are technical people—developers and admins.  (Graham claims that “Our horror at that prospect [of developing for Windows] was the single biggest thing that drove us to start building web apps.”  But I find it hard to believe that this was the primary driver, rather than free distribution, rapid iteration, and all the other benefits of apps in the cloud.)

Apple’s platform strategy with the iPhone was exact:  First, build a large user base without relying on third-party apps—just by building a better phone. Then, once it’s the hottest device on the market, open the platform to developers.  Now, by writing for one device, developers are on a platform getting 100 million downloads a month, several times the rate on other platforms.  The consequence is that as much as developers hate the App Store and its review process, they will continue to develop for iPhone until another platform gives them the same ROI.

The only hope for Android or any other platform is to appeal not to developers, but to users.  Like the downtown bar that offers ladies’-night specials in order to attract the men, attract the users and the developers will follow.

Sean Ellis is blogging again.  I like his blog and his approach, “based more on observing universal truths than inventing some type of methodology.”

His latest post summarizes a lot of what he (and Steve Blank and Eric Ries) have been saying lately.  The whole thing is worth reading, but since it’s long (over 1500 words), here are some highlights.

Ellis recommends finding your “core gratifying experience” early on:

Your objective should be to remove complexity from the initial user experience and messaging in order to highlight this core user perceived value.  Often this means burying or even completely eliminating features that don’t relate to this gratifying experience. [Emphasis added.]

On metrics:

Metrics don’t matter until you achieve product/market fit – then they are critical to your success. . . .  Most of the tools out there provide way too many irrelevant metrics and miss the essential few.

On “extreme customer support”:

Now that you have a business model in place, your first marketing expense should be to expand the customer support team.  Anyone that cares enough about your solution to contact customer support is a great source of insight about your target market.

On building a great customer experience:

While startups often realize the importance of brand experience, they focus on it too early, fine tuning things that customers don’t care about.  Instead, wait until you understand why certain customers love your product; then obsess over every element of this customer experience.

Go read the whole thing.

After yesterday’s post, I found some other folks who have written about the cycle between smart/dumb terminals, thick/thin clients, and centralized/decentralized computing.

Dharmesh Shah wrote “The Thin Client, Thick Client Cycle” at OnStartups in 2006: “One of the repeated cycles I have seen in my 15+ years in the software industry is that we constantly go through this ‘thin client / thick client’ cycle.”  He seems to disagree with what I suggested yesterday, that Web application technology (including JavaScript) might end the cycle, saying:

My thesis now is that we are due for another cycle.  Why?  For the same reason we had the prior cycles:  Because there are still problems with the current model.  User interfaces for true “thin client” applications basically suck. . . .  The problem goes back to the platform . . .  If I were looking to reproduce the user experience of even relatively trivial desktop applications today on the web, it’s hard.

Unclear whether Dharmesh really disagrees with my hypothesis, or if he’s just saying that the developer tools and platforms will evolve to make writing good Web apps much easier.  (He claims, though, that: “What drives these technology cycles as much as user experience is the developer experience.”  Paul Graham implied the same thing in his recent essay: “If programmers used some other device for mobile web access, they’d start to develop apps for that instead.”  I think I disagree, but that’s a post for another time.)

More recently, Hal Pomeranz wrote that “the whole Cloud Computing story felt just like another turn in the epic cycle between centralized and decentralized computing” (“Future Cloudy, Ask Again Later” at Righteous IT, Feb 2009).  He seems to agree with a point I made about the past cycles being driven by economics:

The centralized vs. decentralized cycle keeps turning because in any given computing epoch the costs of all of the above factors rise and fall.  This leads IT folks to optimize one factor over another, which promotes shifts in computing strategy, and the wheel turns again.

Finally, I found a scholarly paper on the subject from 1999 titled “Centralization/decentralization cycles in computing: market evidence” (by D. A. Peak and M. H. Azadmanesh).  Abstract:

Strategies concerning centralized and decentralized commercial computing have been major issues for more than two decades. Using longitudinal sales data consolidated into three major computer categories (mainframes, minicomputers, and microcomputers), we investigate whether historical market data show evidence of centralization and decentralization. Our finding of cyclic behavior leads us to conclude that computing sales data exhibits broadly cyclic characteristics. We suggest that computing strategies oscillate unevenly between domination of centralization and decentralization, and that commercial computing has already experienced two centralization/decentralization cycles. Currently, computing is nearing the end of the second cycle’s decentralization period and is at the threshold of centralization in a third cycle.

Maybe the most important question to ask is:  Why are so many of us in the industry so ignorant of its history?  At least, I feel woefully ignorant of computing history, and I bet I’m not alone.  As with political history in the US today, it seems that most of us only know the history that we lived through.

Anyone know a good source for an overview of the history of the industry, that would cover major trends such as this one?

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.