Rands in Repose

Cloud computing is yet another name for services that have existed for a really long time. Here's the 2008 IEEE Internet Computing quote regarding Cloud Computing:

"Cloud Computing is a paradigm in which information is permanently stored in servers on the Internet and cached temporarily on clients that include desktops, entertainment centers, table computers, notebooks, and wall computers, handhelds, sensors, monitors."

Information stored on servers? Temporary caching? Holy fuck. You mean like those email servers and clients I've been running for 15 YEARS?

The innovation in cloud computing happened years ago. It happened when some bright engineer was trying, for the 185th time, to draw the Internet on a slide, and thought, It's this big, huge, amorphous thing that lacks definition. It's a... cloud.

That's when the magic happened. That's when the name mattered. When it was first used to eloquently and visually describe an idea that lacked mental definition.

Everything that has been happening since then is marketing and wishful thinking. It's those marketing nerds getting paid too much money to rename ideas we've already had. Innovation doesn't come when we give our ideas new names; it comes when the fundamental idea quietly evolves. Innovation often happens silently -- not by what you say, but what you do.

Anywhere. Transparently.

My use case for the cloud hasn't changed in years. I want a single folder sitting somewhere in the cloud that I can transparently access from any computer... anywhere. I'm not greedy; I'll make it even simpler: I'll only put documents in that folder. No applications, no preferences, just my well-defined documents.

I've been trying creatively-named solutions to this use case for a decade. This is how my technology investigations play out:

• Discover
• Install
• Configure the bits
• Give the solution a whirl three times
• Never use it again.

Fact is, getting me to change my information workflow is pretty hard. I'm a creature of habit and efficiency. While I will compulsively give any new idea or tool a try, an application or service needs to fulfill strict requirements.

Just to grab me, you have to:

1. Make it look and feel like magic.
2. Work flawlessly in the first 10 minutes. If you can't survive 10 minutes of critical analysis, I'm gone.
3. Provide additional, unexpected awesomeness.

Like I said, it's tough, and chances are that even if an application meets all of these requirements, I'm going to throw it out because I don't trust it.

I trust Dropbox. Here's why.

Dumb versus Smart

There are two approaches to cloud storage: dumb and smart.

A dumb cloud does just what you'd expect. You attach an external drive or you mount a network directory. It's there. It does nothing unless you remember to manually copy stuff yourself.

A smart cloud combines the external storage with a scheme to do your copying or back-up for you. The idea is that as you change files locally, these changes are detected and sent off to the cloud. Sounds simple enough, right? Brace yourself.

Remember my use case: a single folder sitting somewhere in the cloud that I can transparently access from any computer... anywhere. The key word in that sentence is transparent, and a tool's inability to be transparent is why applications in this space have been a study in failure. I'll explain.

The fail begins with you and your two computers: a portable and a desktop machine. You edit one file on your desktop machine. Fine, the bits get sent to the cloud. Then, you make a different change on the SAME file on your portable, which is NOT on the network. Two hours later, you bring that portable onto the network and what happens? You've got two different versions of that file which both contain original work. Whatever cloud sync tool you are using will likely ask you: "Hey, both of these files have changed. This one was edited this morning and this one was edited two hours later. Which one do you want to keep?"

It's a fair question. Sync is trying to be useful, sync is trying to be helpful, but sync is giving you a choice, and while you are generally good at choices, you will screw up. And when you do you will never, ever blame yourself, you will blame sync.

You will twitter: SYNC FUCKING OVERWROTE MY CHANGES, when all sync was doing was what it was told. See, sync will happily screw you if instructed to do so. By you.

Even though it's my fault, data loss is a colossal disaster in my universe and that means once I figure out data was overwritten, I will not cease my irrational swearing until whatever tool responsible is completely eradicated from my system.

Yet, it is my fault. I chose a solution that was too smart. What I need is for my smart clouds to be dumb.

Dumbing it down with Dropbox

There is nothing new about the idea behind Dropbox. Even the name shows little in terms of innovation. Before I explain how Dropbox gained my trust by solving the sync problem, let's talk about how it grabbed me.

Is it magic? After a simple install and easy account sign-up on the Mac, you end up with a new menu extra. Choosing 'Open your Dropbox' reveals the directory structure of your Dropbox and you're off. Doing what? I don't know -- whatever it is you do. Folders and files thrown into the Dropbox folder are silently synced with the cloud. On the Mac, unless you look closely, it's not even clear what's going on. I had to fire up my portable and set up Dropbox on a second machine to confirm that it was actually doing anything.

The magic of Dropbox is that it doesn't ask you to think about what you do. You care about one thing: do I have access to the most recent version of my files? And with Dropbox, yes, you do. Wherever you are, so are your files.

A flawless 10 minutes. Once I convinced myself that Dropbox was actually doing something, I pushed it. I dumped a large Keynote into Dropbox on one machine and then jumped to another machine and deleted a different file. How long until everything was reconciled? It wasn't instant, the Keynote copy was limited by bandwidth, but it worked flawlessly. And besides, you don't need instant access to your files because you can't be in two places at once. What you want is to never be bothered by the fact that your files are in the cloud. Dropbox is designed to never get in your way... even when you do something stupid. More on this is in a second.

Unexpected awesomeness. While it wasn't in my first 10 minutes, the unexpected awesomeness came when a friend asked for a presentation that wasn't mail server-friendly. He emailed me a link to a shared Dropbox folder, and when I clicked on it, the folder was immediately integrated with my existing Dropbox hierarchy. That's right, I can construct a complex shared hierarchy in the cloud and you know what that complex collaborative beast looked like? My familiar directory structure.

It's these types of design decisions where trust begins.

Trust begins when I can see the design intention of an application. What in NetNewsWire, for example, is the end result of endless fretting over every design angle regarding reading feeds. What I expect is that when I'm stumped, its author, Brent Simmons, has not only thought about why I'm stumped, he's already provided the right feature configured in precisely the right manner to circumvent my stumpedness.

When I use Microsoft Word, I see corporate intent. I see how different warring internal groups tugged the UI to and fro for a decade. I see the intern who did that one feature four years ago. I see a land of misfit toys in the features that haven't been touched in years.

When I'm using Word, I keeping seeing Word, and I don't see what I should be seeing, which is what I am writing. When I'm using Dropbox, I don't even know that I'm using it because it is designed be transparent.

The Screw-Me Scenario

How does Dropbox solve the screw-me sync scenario? To date, Dropbox hasn't said a thing to me. It hasn't given me a single decision to screw up. Dropbox is very smart because it never asks you a thing about sync or any file operation. This is the brilliance: Dropbox knows that any question is a chance to make a wrong decision. And a chance to make a wrong decision is a chance to erode trust.

Yes, you can create the conflict scenario. When it occurs, Dropbox quietly creates a conflict file in your folder and lets you figure out what to do. See, Dropbox isn't going to ask because that's not the model. That's not the design. The Dropbox flow is: "We're not going to bother you with sync because we're just keeping track of you changing stuff and your stuff is only changing when you change it and there is only one of you. If there's a problem, you’ll figure it out when you're good and ready". It's not elegant; I still have to eventually go and clean up the mess, but the more you trust a tool, the less you care about the edge cases.

Dropbox is not dumb. In fact, Dropbox is quite smart because it lets me be dumb.

And I'm dumb. Two weeks ago, I sat down to put the final touches on a presentation. I fired up the portable, looked in the usual Dropbox location and it was empty. Ok, well, I saved it to my desktop, right? Ok, no. Maybe another location inside Dropbox? Ok, no. I can taste it's-deleted-forever adrenalin in the back my mouth now.

Spotlight reveals nothing and I'm starting to blame Dropbox now, so I fire up their web interface, where I discover they keep track of each discrete file operation, and it looks like last night I deleted the presentation in a fit of psychotic folder cleanliness. But here in the Dropbox web interface is every single version of the file that I saved, as well as the ability to restore them.

Click. Restore. And I'm saved.

And that's smart.

As an engineer, if you want to piss off someone who is asking you whether you can or can't build a thing, just say, "Given enough time, I can build anything".

They’ll believe you're dodging the question, and they’ll think you're arrogant.

As a means of negotiating a schedule or a feature, this answer is not helpful. You need to take the time to explain your thinking to this person. You need to walk them through your development process. It's an opportunity to educate and not come off like a jerk.

However.

Given enough time, an engineer can build anything.

I'm optimistic.

And I hire optimists.

Like any profession, software development is chock full of radically different personalities, but I want the optimists. I'm not looking for Yes-folk; I'm looking for those folks who, when backed into a corner with a gun to their heads, respond with, "Fuck it, we're going to figure it out".

This base optimism can be hidden in all types of personalities, but when the shit hits the fan it shows up and often creates the impossible.

In my two decades of working in Silicon Valley, I am happy to confirm that this valley is full of these insane optimists. These are people who:

• Work hard
• Over-commit and still deliver
• Rampantly go out of their way to help each other
• Have a track record of stunning success

This is not a population limited to the valley, it's a population spread across the country and across the globe, but today I'm thinking about my country.

We're nowhere near the bottom of this disaster we've voted onto ourselves. I don't think the majority of Americans fully understand the severity of our financial crisis. We're all fervently staring at Christmas, confusing the holiday spirit for hope.

Yet, I remain optimistic.

Regardless of who wins the election, the question remains, "Do we have it in us to re-invent ourselves? Can we rebuild our country into a place we respect?"

Yes, we can.

I live on the west coast of the United States, which is a region pioneers traveled to so they could choose how to define their home, but this whole country is built on that idea -- we choose who we will be.

Where I sit, with the cranky engineers --the insane optimists -- I hope we all share this optimism because, given enough time, we can build anything.

The lesson of the Holy Shit is that when you stumble upon a truly revolutionary idea, you have the ability to recognize it. There are lots of people who, when they first saw a web page, thought, "I can order pizza on the phone with a live person. Why would I do it on the computer via, what'd you call it? A browser? Also, why is that text blinking?"

You didn't see pizza. You didn't even see the blinking text. In fact, you saw nothing in particular; you just had a gut feeling. There was no logic or strategy behind the gut feeling, it was a sense of deep potential. Your amorphous thought was, “I can’t think of anything I won’t be able to do on the web.”

A Holy Shit is the instant of instinctually recognizing massive potential.

As epiphanies go, Holy Shits are few and far between. My gut says you're lucky if you stumble upon one a year. However, smaller versions happen all the time.

A by-product of obsessively, constantly surfing the net to discover the bright and the shiny is a steady flow of promising new ideas. Mostly slight variations on existing great ideas that tickle your fancy. For example, after staring at Twitter for nearly two years, I'm guessing I've had a dozen bright ideas about Twitter-inspired products. These ideas tend to show up in the morning during the drive, after appropriate caffeination, and more often than not they fade the moment I walk into the office.

But some stick.

My rule is: if I'm still thinking about a bright idea when I'm driving home, it's worth writing down. By passing the idea through my fingers I make it slightly more real... I give it definition.

And then I sleep on it.

The following morning, if I'm still chewing on the bright idea, I start to worry because the logical next step is to pitch a friend. The rule here is: all ideas improve as a function of the number of eyeballs that see them. The troubling converse rule is: as soon as your idea gets out in the wild, it's no longer yours.

In the corporate world, there's a legal instrument to protect bright ideas generated inside of the business and it's called a Non-Disclosure Agreement or an "NDA". When you sign an NDA for a company, you're legally saying, "I’ve agreed to take on the responsibility of protecting and not revealing the company’s intellectual property even if that intellectual property consists of ideas that came out of my head in the first place.”

There are lots of interesting variations of the NDA, but the two significant ones are: the Two-Way and the One-Way.

The Two-Way NDA says, "Anything either of us says is private". The more scary One-Way states, "We can use anything you say, but you can't use anything we say".

Neither of these legal instruments is useful to me when I merely want to pitch a friend about my idea. The concept of getting Phil to sign an NDA over a beer while we shoot the shit about my random drive-to-work idea makes no sense. Phil's a friend.

But I want Phil to know that what I want to chat about is more than our average conversation. I want slightly more than a smidge of ceremony before I spill the beans about my bright idea and I call this ceremony the FriendDA.

The FriendDA is a non-binding, warm blanket agreement that offers absolutely no legal protection. I'd suggest if the idea of legal protection is even crossing your mind that the FriendDA is totally inappropriate for your current needs.

Take a look.

Ideally, the understanding you want to get to with the FriendDA requires only a simple question. The moment you're about to pitch Phil on the idea you ask, "FriendDA?"

Phil takes a sip of beer and nods.

And you're off.

They played bridge every Wednesday at Netscape. In the middle of the cafeteria. Like clockwork.

The players were a collection of ex-SGI guys and they worked for a variety of different groups at the company, but as I learned a few months later, this core group of men quietly defined the engineering culture of the company... with a bridge game.

Ninety Days

If you follow the rules in Ninety Days, you're going to have a solid feel for the construction of your immediate team. Who is who. Who does what. What they know. Who the freak is. Who the free electron is. In a start-up when there are only 12 of you, you're done. You know the people landscape because, from where you sit, you can see them all and you interact with all of them regularly. In a larger company, however, ninety days is only going to give you a brief glimpse of what you need to know about your co-workers, the company, and its culture.

Fortunately, in a large company, tools and documents have been created to help you traverse the culture and process and figure out where people fit. For example, what do you do when you get a random urgent mail from a co-worker stranger? Even if the stranger takes the time to explain who they are and what they do, you still fire up the corporate directory with the simple question: "Who does this bozo work for?"

The corporate directory is the digital representation of a formerly very important document: the organization chart.

A quick glance at the org chart answers a lot of ego-based questions like:

• Which org does he work in? A cool one?
• How many direct reports does he have? More power?
• How close is he to the CEO? More influence?

As sources of information go, the org chart is essential, but it is an incomplete picture of your company, which brings us back to bridge at Netscape.

Bridge

If you looked up the four core bridge players on the org chart, you'd learn a bit. One engineering manager, another guy from some oddly named platform team, another guy who had a manager title, but no direct reports, and the last guy who looked like a program manager.

My org chart assessment: Meh.

What I learned months later was that the folks sitting at that regular bridge game not only defined much of what became the Netscape browser, they also continued to define the engineering culture or what I think of as a culture chart.

Unlike the org chart, you’re not going to find the culture chart written down anywhere. It doesn’t exist. The culture chart is an unwritten representation of the culture of your company and understanding it answers big questions that you must know:

• What does this organization value?
• Who created this value system?
• Given this value system, who contributes high value?
• Who is most aware of how value is being created?

This is fuzzy philosophical mumbo jumbo, so let's bring it home. In your current job, right now, tell me what it's going take to get you a promotion.

"I need to work really hard."

Ok, so you knew you need to work hard to get a promotion before you set foot in your current gig. My question is, what specific thing do you need to do in order to be promoted? I'd argue that for any engineer who is actively managing their career, it's essential to figure out the answer to this question as quickly as possible, and to do so you need to understand the culture.

Detecting Culture

If you are going to be promoted, you are going to succeed in a group of people when you provide that group things that it think it needs. Now, your gut instinct is that this group of people is the management team, and that's a good org chart-centric answer. The problem is it’s your job to stay ahead of your manager. You’re not going to get promoted giving your manager what he wants; a promotion comes when you give him what he wants as well as what he does not expect, but desperately needs.

It’s unfair. This guy is tasked with your career development and I am saying it’s your job to tell him what he wants. You don’t have to do this; you can take the reactive cues from your boss, but I derive intense professional satisfaction when I deliver the unexpectedly needed and I discover the unexpected by first finding the culture.

To deduce the culture of a company, all you have to do is listen. Culture is an undercurrent of ideas that ties a group of people together. In order for it to exist, it must move from one individual to the next. This is done via the retelling of stories.

"Max was this nobody performance nerd and three weeks before we were supposed to ship, he walked into the CEO’s office with a single piece of paper with a single graph. He dropped the graph on the table, sat down, and said, ‘No way we ship in three weeks. Six months. Maybe.’ The CEO ignored the paper, ‘We lose three million dollars if we don’t.’ Max stood up, pointed at the chart, and said, ‘We lose ten if we do. We must not ship crap.”

Whether this story is true or not is irrelevant. The story about how Max saved the company ten million dollars by telling the CEO “No” is retold daily. In hallways. At the bar over beers. The story continually reinforces an important part of this company's culture.

We must not ship crap.

There isn't a corporate values statement on the planet that so brutally and beautifully defines the culture of a company.

There are other stories that you're going to hear over and over again, and inside each of these stories are the real corporate values. Each one, while designed to be entertaining, teaches a lesson about what this particular company values, and these are the lessons that are going to get you promoted.

There's a chance you're not going to find these stories. My hope is that you're in a company where engineering is valued and, as such, has an influence on the culture of your company. If it's been six months, you’ve been actively looking, and no one has told you a great story about how engineering shaped the fortunes of your company, there's a chance that in your company engineering doesn't have a seat at the culture table. My question is then, "How are you going to succeed, how are you going to be promoted, where engineering isn't an influential part of the culture?"

Culture Definers

After you have a healthy collection of stories, you're going to have a good idea about some of the culture, but you're still missing essential data for your culture chart. See, the folks who tell the stories about culture usually aren't the folks who created them.

Stories are told, but first they are born.

The people who are responsible for defining the culture are not deliberately doing so. They do not wake up in the morning and decide, "Today is the day I will steer the culture of the company to value quality design".

They just do it. The individuals who have the biggest impact on the culture and company aren't doing it for any other reason than they believe it is right thing to do, and if you want to grow in this particular company it's a good idea to at least know who they are and where they sit. You need to pay attention to this core group of engineers because as they do, so will the company.

Game Over

Your company is networked in more ways than you can possibly imagine. Just because you've reverse engineered the development culture in your organization doesn't mean you've got a complete map of the overall culture. There are endless connections tugging any decent sized group of people in multiple directions at once. There’s the been-here-forever network, the I-survived-the-layoff people, and the untouchable-did-something-great-once crew.

Culture assessment is an information game and it's never over. Your job is to continually situate yourself in such as a way that, as quickly as possible, you can assess subtle changes in the culture of your company.

I wasn't concerned when Netscape started losing market share to Microsoft. I didn't sweat it when the stock price stalled. The reason I started thinking about my next gig was, months before either of these two events occurred, one of the lunchtime bridge team left.

The game stopped. The small group of four no longer spent a long lunch quietly, unknowingly defining the culture of the company and everyone who was watching noticed.

They noticed when one of those who had humbly done the work that defined the company no longer believed enough to stay.