too long to tweet

About a year ago, we at Affirm decided to add an OKR to our annual planning titled “High-Performance Culture”, to help shore up the necessary means (for the necessary means) of improving our collective productivity. (Yes yes, big company stuff, whatever – we grew revenue 46% last fiscal year on essentially flat headcount, that’s pretty addictive, and it doesn’t hurt the stock price.)

We measure this OKR by asking every Affirmer a handful of questions about their experience getting work done, eg “do you feel like it’s pretty collaborative here”, etc, scoring it on a 10pt scale, and trying to improve our score quarter to quarter. Generally, our score’s pretty high, and trending gently higher, so all good then?

Maybe, but how do you do better? High-performance culture is pretty easy to define: a culture of individuals doing productive work for the company in the most efficient way possible and helping others do the same, while generally having a good time. But what do you actually do [sir] to have such a culture? And what do you not do? 

So I jotted down a few incomplete one-liners of what that means to me as Affirm’s founder and CEO. This list is neither exhaustive (I reserve the right to add and remove things here) nor is it even especially well-organized, but culture is like obscenity in Jacobellis v Ohio: you know it when you see it. 

So here’s what I see at Affirm. 

mission

morality is a key ingredient in everything we do (and don’t do)

integrity is what got us where we are today, never compromise it

consumers, merchants, and capital partners are who we serve

stay humble and be curious about the needs of each of our constituents

take pride in providing safe access to fair credit; don’t judge what consumers use it for

bleed the colors, the values, the mission

merit

Affirm is a meritocracy: your talent, skill, and willingness to put it all to work define you here

we solve multivariate optimization problems – a certain minimum intellectual capacity is required

demand excellence from yourself and from your teammates, don’t settle

work-life balance tends to take care of itself if you love your work

…remember that this is a marathon – take care of yourself and those you love

if you can’t keep up, we’ll try our best to help, but eventually you may have to leave

if you see that someone can’t keep up, you should step in to help them

leadership

we are a culture of individuals working together as teams  

once someone is a part of the team, fully accept them as one of our own

whom you hire, and how you help them be productive is your top responsibility 

be an owner, not merely an employee

do not allow “us and them” dynamics to foment anywhere at Affirm

run towards a problem; don’t assume someone else will take care of it

be a stress absorber for your team, not a stress amplifier

an occasional heroic act that helps Affirm win is a good thing, not a sign of poor planning

constant heroic acts required for Affirm to survive is a sign of poor planning

lead by example

how we work

we take calculated risks – do the calculating!

make reversible decisions fast

bring the bad news to the team early – we’ll rally to help

use our product and understand its value to our customers

care about how we make things — mind the quality of the invisible parts

…do not let perfect be the enemy of shipping and iterating

time is the scarcest resource we have, be mindful of how you use yours, and your team’s

we are a writing culture, favor short, pithy n-pagers to novels or live rants

post-mortem everything: the successes, the failures, and the near-misses – and learn

we take our work extremely seriously — but not so much ourselves 

how we disagree

if you disagree, you must speak up, even escalate – especially before a decision is made

fear of being wrong is not an acceptable reason for not speaking up

never accept an unexplained “no” for an answer – ask why

challenge ideas! good ones can handle the scrutiny, bad ones need to die on the vine

even the harshest critique of your idea is not an attack on you, don’t take it as such

no matter how brilliant you are, being a jerk is a ticket out of Affirm

know our business well, and know your area of the business cold

argue using facts whenever possible, but give your gut a voice too

once the decision is reached, commit 

It’s 3am. Paul, the head of PayPal database administration carefully enters his elaborate passphrase at a keyboard in a darkened cubicle of 1840 Embarcadero Road in East Palo Alto, for the fifth time. He hits Return. The green-on-black console window instantly displays one line of text: “Sorry, one or more wrong passphrases. Can’t reconstruct the key. Goodbye.” 

There is nerd pandemonium all around us. James, our recently promoted VP of Engineering, just climbed the desk at a nearby cubicle, screaming: “Guys, if we can’t get this key the right way, we gotta start brute-forcing it ASAP!” It’s gallows humor – he knows very well that brute-forcing such a key will take millions of years, and it’s already 6am on the East Coast – the first of many “Why is PayPal down today?” articles is undoubtedly going to hit CNET shortly. Our single-story cubicle-maze office is buzzing with nervous activity of PayPalians who know they can’t help but want to do something anyway. I poke my head up above the cubicle wall to catch a glimpse of someone trying to stay inside a giant otherwise empty recycling bin on wheels while a couple of Senior Software Engineers are attempting to accelerate the bin up to dangerous speeds in the front lobby. I lower my head and try to stay focused. “Let’s try it again, this time with three different people” is the best idea I can come up with, even though I am quite sure it will not work. 

It doesn’t. 

The key in question decrypts PayPal’s master payment credential table – also known as the giant store of credit card and bank account numbers. Without access to payment credentials, PayPal doesn’t really have a business per se, seeing how we are supposed to facilitate payments, and that’s really hard to do if we no longer have access to the 100+ million credit card numbers our users added over the last year of insane growth. 

This is the story of a catastrophic software bug I briefly introduced into the PayPal codebase that almost cost us the company (or so it seemed, in the moment.) I’ve told this story a handful of times, always swearing the listeners to secrecy, and surprisingly it does not appear to have ever been written down before. 20+ years since the incident, it now appears instructive and a little funny, rather than merely extremely embarrassing. 

Before we get back to that fateful night, we have to go back another decade. In the summer of 1991, my family and I moved to Chicago from Kyiv, Ukraine. While we had just a few hundred dollars between the five of us, we did have one secret advantage: science fiction fans. 

My dad was a highly active member of Zoryaniy Shlyah – Kyiv’s possibly first (and possibly only, at the time) sci-fi fan club – the name means “Star Trek” in Ukrainian, unsurprisingly. He translated some Stansilaw Lem (of Solaris and Futurological Congress fame) from Polish to Russian in the early 80s and was generally considered a coryphaeus at ZSh. 

While USSR was more or less informationally isolated behind the digital Iron Curtain until the late ‘80s, by 1990 or so, things like FidoNet wriggled their way into the Soviet computing world, and some members of ZSh were now exchanging electronic mail with sci-fi fans of the free world.

The vaguely exotic news of two Soviet refugee sci-fi fans arriving in Chicago was transmitted to the local fandom before we had even boarded the PanAm flight that took us across the Atlantic [1]. My dad (and I, by extension) was soon adopted by some kind Chicago science fiction geeks, a few of whom became close friends over the years, though that’s a story for another time. 

A year or so after the move to Chicago, our new sci-fi friends invited my dad to a birthday party for a rising star of the local fandom, one Bruce Schneier. We certainly did not know Bruce or really anyone at the party, but it promised good food, friendly people, and probably filk. My role was to translate, as my dad spoke limited English at the time. 

I had fallen desperately in love with secret codes and cryptography about a year before we left Ukraine. Walking into Bruce’s library during the house tour (this was a couple years before Applied Cryptography was published and he must have been deep in research) felt like walking into Narnia. 

I promptly abandoned my dad to fend for himself as far as small talk and canapés were concerned, and proceeded to make a complete ass out of myself by brazenly asking the host for a few sheets of paper and a pencil. Having been obliged, I pulled a half dozen cryptography books from the shelves and went to work trying to copy down some answers to a few long-held questions on the library floor. After about two hours of scribbling alone like a man possessed, I ran out of paper and decided to temporarily rejoin the party. 

On the living room table, Bruce had stacks of copies of his fanzine Ramblings. Thinking I could use the blank sides of the pages to take more notes, I grabbed a printout and was about to quietly return to copying the original S-box values for DES when my dad spotted me from across the room and demanded I help him socialize. The party wrapped soon, and our friends drove us home. 

The printout I grabbed was not a Ramblings issue. It was a short essay by Bruce titled Sharing Secrets Among Friends, essentially a humorous explanation of Shamir Secret Sharing. 

Say you want to make sure that something really really important and secret (a nuclear weapon launch code, a database encryption key, etc) cannot be known or used by a single (friendly) actor, but becomes available, if at least n people from a group of m choose to do it. Think two on-duty officers (from a cadre of say 5) turning keys together to get ready for a nuke launch. 

The idea (proposed by Adi Shamir – the S of RSA! – in 1979) is as simple as it is beautiful. 

Let’s call the secret we are trying to split among m people K. 

First, create a totally random polynomial that looks like: y(x) = C0 * x^(n-1) + C1 * x^(n-2) + C2 * x^(n-3) ….+ K. “Create” here just means generate random coefficients C. Now, for every person in your trusted group of m, evaluate the polynomial for some randomly chosen Xm and hand them their corresponding (Xm,Ym) each. 

If we have n of these points together, we can use Lagrange interpolating polynomial to reconstruct the coefficients – and evaluate the original polynomial at x=0, which conveniently gives us y(0) = K, the secret. Beautiful. I still had the printout with me, years later, in Palo Alto. 

It should come as no surprise that during my time as CTO PayPal engineering had an absolute obsession with security. No firewall was one too many, no multi-factor authentication scheme too onerous, etc. Anything that was worth anything at all was encrypted at rest. 

To decrypt, a service would get the needed data from its database table, transmit it to a special service named cryptoserv (an original SUN hardware running Solaris sitting on its own, especially tightly locked-down network) and a special service running only there would perform the decryption and send back the result. 

Decryption request rate was monitored externally and on cryptoserv, and if there were too many requests, the whole thing was to shut down and purge any sensitive data and keys from its memory until manually restarted. 

It was this manual restart that gnawed at me. At launch, a bunch of configuration files containing various critical decryption keys were read (decrypted by another key derived from one manually-entered passphrase) and loaded into the memory to perform future cryptographic services.

Four or five of us on the engineering team knew the passphrase and could restart cryptoserv if it crashed or simply had to have an upgrade. What if someone performed a little old-fashioned rubber-hose cryptanalysis and literally beat the passphrase out of one of us? The attacker could theoretically get access to these all-important master keys. Then stealing the encrypted-at-rest database of all our users’ secrets could prove useful – they could decrypt them in the comfort of their underground supervillain lair. 

I needed to eliminate this threat.

Shamir Secret Sharing was the obvious choice – beautiful, simple, perfect (you can in fact prove that if done right, it offers perfect secrecy.) I decided on a 3-of-8 scheme and implemented it in pure POSIX C for portability over a few days, and tested it for several weeks on my Linux desktop with other engineers. 

Step 1: generate the polynomial coefficients for 8 shard-holders.

Step 2: compute the key shards (x0, y0)  through (x7, y7)

Step 3: get each shard-holder to enter a long, secure passphrase to encrypt the shard

Step 4: write out the 8 shard files, encrypted with their respective passphrases.

And to reconstruct: 

Step 1: pick any 3 shard files. 

Step 2: ask each of the respective owners to enter their passphrases. 

Step 3: decrypt the shard files.

Step 4: reconstruct the polynomial, evaluate it for x=0 to get the key.

Step 5: launch cryptoserv with the key. 

One design detail here is that each shard file also stored a message authentication code (a keyed hash) of its passphrase to make sure we could identify when someone mistyped their passphrase. These tests ran hundreds and hundreds of times, on both Linux and Solaris, to make sure I did not screw up some big/little-endianness issue, etc. It all worked perfectly. 

A month or so later, the night of the key splitting party was upon us. We were finally going to close out the last vulnerability and be secure. Feeling as if I was about to turn my fellow shard-holders into cymeks, I gathered them around my desktop as PayPal’s front page began sporting the “We are down for maintenance and will be back soon” message around midnight.

The night before, I solemnly generated the new master key and securely copied it to cryptoserv. Now, while “Push It” by Salt-n-Pepa blared from someone’s desktop speakers, the automated deployment script copied shard files to their destination. 

While each of us took turns carefully entering our elaborate passphrases at a specially selected keyboard, Paul shut down the main database and decrypted the payment credentials table, then ran the script to re-encrypt with the new key. Some minutes later, the database was running smoothly again, with the newly encrypted table, without incident. 

All that was left was to restore the master key from its shards and launch the new, even more secure cryptographic service. 

The three of us entered our passphrases… to be met with the error message I haven’t seen in weeks: “Sorry, one or more wrong passphrases. Can’t reconstruct the key. Goodbye.” Surely one of us screwed up typing, no big deal, we’ll do it again. No dice. No dice – again and again, even after we tried numerous combinations of the three people necessary to decrypt. 

Minutes passed, confusion grew, tension rose rapidly. 

There was nothing to do, except to hit rewind – to grab the master key from the file still sitting on cryptoserv, split it again, generate new shards, choose passphrases, and get it done. Not a great feeling to have your first launch go wrong, but not a huge deal either. It will all be OK in a minute or two.

A cursory look at the master key file date told me that no, it wouldn’t be OK at all. The file sitting on cryptoserv wasn’t from last night, it was created just a few minutes ago. During the Salt-n-Pepa-themed push from stage, we overwrote the master key file with the stage version. Whatever key that was, it wasn’t the one I generated the day before: only one copy existed, the one I copied to cryptoserv from my computer the night before. Zero copies existed now. Not only that, the push script appears to have also wiped out the backup of the old key, so the database backups we have encrypted with the old key are likely useless. 

Sitrep: we have 8 shard files that we apparently cannot use to restore the master key and zero master key backups. The database is running but its secret data cannot be accessed. 

I will leave it to your imagination to conjure up what was going through my head that night as I stared into the black screen willing the shards to work. After half a decade of trying to make something of myself (instead of just going to work for Microsoft or IBM after graduation) I had just destroyed my first successful startup in the most spectacular fashion. 

Still, the idea of “what if we all just continuously screwed up our passphrases” swirled around my brain. It was an easy check to perform, thanks to the included MACs. I added a single printf() debug statement into the shard reconstruction code and instead of printing out a summary error of “one or more…” the code now showed if the passphrase entered matched the authentication code stored in the shard file. 

I compiled the new code directly on cryptoserv in direct contravention of all reasonable security practices – what did I have to lose? Entering my own passphrase, I promptly got “bad passphrase” error I just added to the code. Well, that’s just great – I knew my passphrase was correct, I had it written down on a post-it note I had planned to rip up hours ago. 

Another person, same error. Finally, the last person, JK, entered his passphrase. No error. The key still did not reconstruct correctly, I got the “Goodbye”, but something worked. I turned to the engineer and said, “what did you just type in that worked?”

After a second of embarrassed mumbling, he admitted to choosing “a$$word” as his passphrase. The gall! I asked everyone entrusted with the grave task of relaunching crytposerv to pick really hard to guess passphrases, and this guy…?! Still, this was something -- it worked. But why?!

I sprinted around the half-lit office grabbing the rest of the shard-holders demanding they tell me their passphrases. Everyone else had picked much lengthier passages of text and numbers. I manually tested each and none decrypted correctly. Except for the a$$word. What was it…

A lightning bolt hit me and I sprinted back to my own cubicle in the far corner, unlocked the screen and typed in “man getpass” on the command line, while logging into cryptoserv in another window and doing exactly the same thing there. I saw exactly what I needed to see. 

Today, should you try to read up the programmer’s manual (AKA the man page) on getpass, you will find it has been long declared obsolete and replaced with a more intelligent alternative in nearly all flavors of modern Unix.  

But back then, if you wanted to collect some information from the keyboard without printing what is being typed in onto the screen and remain POSIX-compliant, getpass did the trick. Other than a few standard file manipulation system calls, getpass was the only operating system service call I used, to ensure clean portability between Linux and Solaris. 

Except it wasn’t completely clean. 

Plain as day, there it was: the manual pages were identical, except Solaris had a “special feature”: any passphrase entered that was longer than 8 characters long was automatically reduced to that length anyway. (Who needs long passwords, amiright?!)

I screamed like a wounded animal. We generated the key on my Linux desktop and entered our novel-length passphrases right here. Attempting to restore them on a Solaris machine where they were being clipped down to 8 characters long would never work. Except, of course, for a$$word. That one was fine.

The rest was an exercise in high-speed coding and some entirely off-protocol file moving. We reconstructed the master key on my machine (all of our passphrases worked fine), copied the file to the Solaris-running cryptoserv, re-split it there (with very short passphrases), reconstructed it successfully, and PayPal was up and running again like nothing ever happened. 

By the time our unsuspecting colleagues rolled back into the office I was starting to doze on the floor of my cubicle and that was that. When someone asked me later that day why we took so long to bring the site back up, I’d simply respond with “eh, shoulda RTFM.” 

RTFM indeed. 

P.S. A few hours later, John, our General Counsel, stopped by my cubicle to ask me something. The day before I apparently gave him a sealed envelope and asked him to store it in his safe for 24 hours without explaining myself. He wanted to know what to do with it now that 24 hours have passed. 

Ha. I forgot all about it, but in a bout of “what if it doesn’t work” paranoia, I printed out the base64-encoded master key when we had generated it the night before, stuffed it into an envelope, and gave it to John for safekeeping. We shredded it together without opening and laughed about what would have never actually been a company-ending event. 

P.P.S. If you are thinking of all the ways this whole SSS design is horribly insecure (it had some real flaws for sure) and plan to poke around PayPal to see if it might still be there, don’t. While it served us well for a few years, this was the very first thing eBay required us to turn off after the acquisition. Pretty sure it’s back to a single passphrase now. 

Notes:

Saturday, May 12th, I had the enormous honor of being the commencement speaker at my Alma Mater (CS Eng’97), University of Illinois at Urbana Champaign, on the 150th anniversary of UIUC’s very first class.

My heart was overflowing with pride looking over the veritable sea of orange and blue in full academic regalia on the Memorial Field, and a giant cheering crowd of relatives and friends in the stands.I am not sure this was my best speech or delivery ever, but it was certainly the most heartfelt one. 

At some point, I will find the video of the thing, but for now here’s the full text. The video is here: https://mediaspace.illinois.edu/media/t/1_il5k6pi4 -- I am on at 54 minutes in. Full text is also below. 

Huge thanks to Elizabeth Allin, Lia Ballard, Brooks Hosfield, and the ever-faithful Ryan Metcalf, who helped me get this written, polished, practiced, and delivered, stress-free (though not for them!) and on time.

First of all, I’d like to thank the University, and the Chancellor, and the President, for inviting me to be here.

Thank you to my family, who braved all kinds of travel to come.

I cannot overstate how honored and proud I feel to be at this podium. In this hot wind, breathing in the familiar aroma of South Farms, and addressing all of you.

I loved my time at U of I, and I take great pride in being an Illinois alumnus! And, I am happy to report, your Chambana-conferred degree will serve as a badge of honor out there in the real world.

I graduated 21 years ago, which sounds like a century to me, and feels like yesterday. So while I don’t feel especially qualified dispensing “life advice”, I do have a few experiences on you -- some good, some awful. I will share three of these with you, hoping you’ll find them amusing, and maybe even useful.

The first one is about taking risks and getting lucky.

I got insanely lucky.

I was born in the Soviet Union. By the time I reached my teens, in the late ‘80s, the country was being held together with shoestring and bubblegum.

But because it was Soviet-made bubble gum, it was made out of tree bark and superglue.

Worried about political and economic instability and the rise of anti-Semitism, my family thought of immigrating. United States allowed us to enter as political refugees. And for that, we are forever grateful.

Meanwhile, in 1986, the Chernobyl Nuclear Power station blew itself up in the worst nuclear accident ever. Which was unfortunate, because Kiev, where I was born, was only 90 miles away.

Leaving everything behind and moving to America felt like a huge risk, but the nuclear disaster close by really motivated my family to get moving. We made it to the US in 1991, with about $600 between the five of us.

I was 16, so I got to experience Chicago Public Schools for two years and was pretty confused about college selection process. My high school guidance counsellor suggested U of I serendipitously, because my two-year streak of amazing science fair victories made me eligible for some sweet state scholarships, and a heavily subsidized student loan.

At this very time, National Center for Supercomputing Applications, right here on campus, launched Mosaic, the first graphical web browser that would soon change science, commerce, information, learning,.. everything.

And I was going to study the most relevant discipline for this new age, at the most relevant place to study it.

And that is how I ended up at the University of Illinois, on Quad Day 1993, in blazing 100+-degree heat, wearing a Soviet-made flannel shirt buttoned all the way up, and sporting a medium-size fro.

I walked up to a gaggle of similarly smartly-dressed nerds crowding around a computer, squinting in the bright sun.

And I knew I’d found my people, and their land was called Digital Computer Lab.

During those glorious days in DCL, I didn’t sleep very much -- but when I slept, I often slept in a chair, in front of a computer.

Once, as I was dozing off at the ACM office, after another programming marathon, too tired to go get another Mountain Dew, entirely out of junk food, these two engineering students walked by.

I sort of knew them, but not well. One was a year ahead of me, the other was one year behind.

They casually asked me what I was doing up so late, and I showed off the latest computer graphics project. They were up late because they were going to start a company.

Since I enjoyed programming so much, and appeared to be able to live on sugary drinks and almost no sleep -- they said -- how would I like to join them as their first Vice President of Engineering?

It felt risky. I could have just gone downstairs to the candy machine, to procure another Dew and Snickers. Thus rejuvenated, I could have just gone back to building fun academic projects, graduated, stayed on for grad school, gotten a doctorate, and probably became a Computer Science professor, perhaps even a good one.

(I am fairly sure my Mom is still kinda hoping for this version to happen.)

But the choice I made that moment wound up changing my life forever.

I mumbled something along the lines of “Starting a company? Rad, count me in,” though I had absolutely no idea of what that actually meant.

But I was curious, and I had nothing to lose except for my GPA, and our first startup was born.

These guys turned out to know a lot more about starting companies (and lots of other things) than I did, and pretty soon I was working extra-hard just trying to keep up. I slept even less, programmed even more, and was generally having a great time.

Unfortunately, we didn’t know quite enough. Our startup failed, about a year later. The company didn’t leave much of a dent in the universe, but it sure dented my GPA!

And my credit score, because right before we totally ran out of money, it was being financed entirely by our student credit cards.

Basically, it was a disaster.

But, I knew that entrepreneurship was going to be my path. It turned out that starting a business, and watching it grow through hard work, brought me so much joy, I knew I couldn’t do anything else.

When I look back at that moment, I really wonder just how the fresh-off-the-boat, risk-averse, grad school-material 19-year-old Max managed to work up the nerve to give this crazy startup thing a try.

Yes, my judgement was impaired by sleep deprivation, and I had very little to lose, but most importantly it was curiosity.

I failed, but I found to out who I really was -- I found my calling.

This brings me to my second story (and I will keep this one shorter).

Second story is that failure always hurts, and you live through it by staying human.

One thing worth noting is that risk-taking does not guarantee immediate success.

In fact, it pretty much does the opposite. After that first company failed, I stayed here, and tried to wrap up my Bachelor’s degree as quickly as I could.

I kept on starting companies on campus, and they just kept on failing. Four companies, in the span of three years. Each went the way of the dodo in a year or less.

But I loved starting them up, coming up with one hare-brained business idea after another. And they just kept. on. failing.

My girlfriend at the time got so fed up with this, she broke up with me by ripping up my business registration certificate right in front of my face, to make a point.

Thing is, I didn’t mind too much, because that company failed already and I needed to register a new one anyway. I did, and it hurt exactly the same when that one failed too.

Finally, I graduated, and moved to where they had more venture capital than cornfields: Palo Alto, California. Almost by accident, I met this guy Peter Thiel, and we founded a company together. That company ended up being PayPal, and that one finally didn’t fail.

Incidentally, I have a public service announcement!

if your account has been frozen by PayPal, please do not email me, or grab me after this speech -- it’s been well over a decade since I had anything to do with PayPal. So stop asking me to unlock your account!

After PayPal, failure seemed to have finally let me off the hook. This time, I told myself, I was going to start a company that was going to be even bigger, change the world more, make a bigger dent!

None of those things happened, but that next startup taught me my most painful lesson yet: failing people who trust in you, hurts a lot more than just failing yourself.

We built a great team, and grew extremely fast for a while, but I got over my skis, and we almost ran out of money, and I had to lay off a bunch of employees.

That feeling you get when you explain to a roomful of wide-eyed people that you screwed up, that you didn’t budget well, that you failed to find the money for their salaries, and that they now have to find a new place to work… it’s not fun.

You’d think that with the number of failures I’d accumulated by then my skin would be as thick as a rhino’s, but no such luck.

It hurt terribly when I had to lay people off… and even worse when I had to do it again, a few months later.

A wise colleague who’d been around his fair share of business failure, told me something that dark day: go be a human, not a Chief Executive.

We are all hurting, not just you. Instead of feeling sorry for yourself in a corner conference room, go help those you just let go to pack up their stuff, and show some compassion.

And so I did.

It took some willpower to walk out, to talk to, and to hug the people I felt I had failed so profoundly. I expected a lot of anger and resentment, but instead mostly felt compassion and forgiveness.

They understood I tried my best. We were all hurting, but it was slightly easier to cope with it as a team, one last time.

Stories about Silicon Valley often over-glamorize failure. We shot the moon, we fell short -- but hey, it was a good try, no big deal.

That’s simply not true: failing sucks. There is no getting around the pain you experience when you fail, and it doesn’t get much easier with experience.

But don’t let fear of failure deter you from taking those risks.

Surround yourself with people who will help you cope with the darkest moments, be a human, and you will survive, and ultimately thrive. Which brings me to my final story.

That is, be with people who make you want to be a better you.

If there is one trope in Silicon Valley, and the business world in general, that is actually true it is  that it’s all about the people.

A so-so business plan, and an incredible team are far more likely to succeed than a mediocre team with a plan to take over the world.

And it’s not just about having the best individual players -- their interpersonal relationships, their empathy for each other, trust and respect, all matter.

The early days of PayPal were just as crazy as all the other previous startups. We almost ran out of money, twice.

We changed our business model six times, and replaced our Chief Executive Officers three times in four months.

International organized crime tried to kill our company, and so did several giant Wall Street banks, inconveniently, all at the same time!

As PayPal grew to be a major success, I’ve been asked repeatedly, what was it about the people that made up our early team, that enabled PayPal to persevere, even as many competitors fell to the same challenges?

I think I know the answer now.

We didn’t exactly start out an amazing team. We were all young, curious, and willing to take huge risks, and had nothing to lose. But single most important factor was: none of us took our spot on this team for granted. Every one of us felt the rising expectations from the rest, and so each one tried to be the very best we could be. And then improve on that.

Right around those early PayPal times I met the woman who eventually became my wife, Nellie (hi!). Trying to impress her became my lifelong project -- because keeping up with her growth has been the the single funnest challenge of my life.

So, if there is one piece of advice I will allow myself from this stage, let it be relationship advice!

Whether you are starting a company, or joining one, or even thinking about a life partner: ask yourself, how motivated do you feel to become an even better version of you?

If yes, you’ve found something (or someone) truly special -- join that team.

Because of some crazy coincidences, a nuclear accident, and some fantastic science fair displays, I lucked into the innovation of modern era, and met some amazing people, who shaped my own life.

People whose brilliance, and thirst for knowledge, and quest for constant self-improvement pushed me to try to be better too.

And you don’t have to wait to meet the amazing people in your own life, because you have almost certainly already met them.

I followed a couple U of I friends to take a risk I never expected myself to take, to discover my life’s passion, failing all the way to the eventual lucky break.

Those two wild and crazy guys who put me up to all this madness, both worked on PayPal from its earliest days, and we still work together on new projects today.

The first two dozen of PayPal’s software engineers were also my U of I classmates.

It’s been two decades’ worth of companies and projects, and we continue to work together, and support each other.

From Yelp to YouTube both of which were founded by U of I grads from the PayPal network.

The friendships you forged here, at Illinois, are going to turn out to be the foundational relationships of your life.

So, go out there, take risks to find you who you really are!

Fail passionately and recover quickly!

And find, and hang on tight to those who make you a better you!

Which brings me to my final point: don’t wait to take the first risk.

As you accumulate success, especially financial success, you start growing barnacles of comfort.

A nice car you can finally afford, a place you enjoy coming home to, even a family -- all those things don’t just sound nice. They are nice. And they are powerful motivators to change nothing.

So, class of 2018, whatever your definition of risk is, go experience it now, while your entire life is ahead of you, and you have almost nothing to lose.

You might just find out who you really are.

In 2011, I started HVF as a container entity for all sorts of data-related projects: ideation, incubation, investing, other things starting with letter 'i'. In the last 5 years HVF has been a highly rewarding exercise in both thinking and doing. We incubated and seeded Glow and Affirm, the latter of which I am now running full time, and invested in over 50 startups.

America has always been a safe haven and the land of opportunity for those whose only choice is to leave it all behind. My family and I, and thousands of Soviet Jews like us, came here as refugees in 1991, running from an unjust regime that persecuted us simply for who we were. As a nation of many immigrants (not all, though!), we must not close our doors to refugees, and those willing to contribute to America's success.

National security is essential, but I believe it makes a lot more sense to address individual threats. The blunt tool of barring entire countries from entry uses up the resources that can be put to smarter use. This policy has already disrupted numerous families of patriotic Americans, and is distressing to many more. I don't believe core American values are being represented in these orders.

A hallmark of a good executive is the ability to swiftly correct erroneous decisions. I hope the President and his cabinet consider the impact of these executive orders carefully. 

I loved math and puzzles for as long as I can remember, but my love affair with cryptography began when a fellow student at the University of Illinois at Urbana-Champaign let me borrow his many-times-xerox’d copy of the government-issued technical specification of the Digital Encryption Standard in 1994. (Thank you Dave B., I don’t think I ever returned it!). I was hooked, and even tried to apply to the NSA for an internship, but was promptly rebuffed because I was not (yet) a U.S. citizen.

Instead, swept up in the first Internet startup wave, I was dreaming up schemes to build a crypto-powered startup. Having moved to Silicon Valley after graduation, I started a company with a guy I met on Stanford campus, Peter Thiel, to do just that — build a company where security was the ultimate source of value creation. The company, which we initially called Confinity (for Confidence and Infinity) was soon renamed PayPal.

A less public guy, whom I also met at Stanford, is helping award this prize today — Professor Dan Boneh. Dan has been an invaluable helper, sanity-checker, and occasional life- (or at least company-) saver as we designed our security systems at PayPal, and in almost every other project I’ve since gone on to start. (In fact, Dan once helped identify and fix a very ugly software bug in the seed material collector for my random-number generator… instead of going to his own birthday party.)

Despite never having the patience to complete an advanced degree (which remains my science-minded family’s goal) in cryptography, its applications in the real world remained a critical enabler of much of my success to date.

So, in October of 2014, I invited a few friends, practitioners and experts in cryptography, to dinner, to discuss the best way to celebrate and promote applied, real-world cryptography and its applications in digital security, as well as aid in broader public awareness of the importance of both. It was that dinner where this prize was born and today,  I am proud to announce the first two recipients of the 1st annual Levchin Prize for Real-World Cryptography.

Winner 1: Phillip Rogaway

Significance of contribution: Phil is a giant in the area of symmetric encryption. The prize is given for his groundbreaking practice-oriented research, authenticated encryption and his work on format preserving encryption which has had an exceptional impact on real-world cryptography.

Winner 2:  The miTLS Team

Significance of contribution: miTLS is a verified implementation of the TLS protocol. In addition to the implementation, the team also uncovered numerous mistakes in the design of TLS and mistakes in many implementations. Their work has influenced the design of many features in the upcoming update to TLS called TLS 1.3.

I created this prize because I believe technological innovation can improve electronic freedom, privacy, trustworthiness, and safety.  All of us use - and benefit from - applications of cryptography in our daily lives. More than anything, this prize is about drawing attention to the contributions of those in the field and recognizing that cryptography is very special field, in and of itself.

I hope that this prize encourages younger researchers – especially students – to think about how cryptographic principles can be applied to improve the many flawed systems of today. At a time when governments and corporations are scrambling to stem the rising tide of data breaches, cryptography has never been more important to the security of our economy and our personal privacy.

As we grow Affirm, our ability to translate our ambitious mission (Improve lives through honest financial products!), governed by our core values (Focus, Boldness, Excellence, Transparency, and Responsibility), into a cogent day-to-day strategy becomes essential.

Truly great companies retain a deep, intimate sense of shared of understanding even as they expand exponentially. I wrote down the following operating principles to help create this shared understanding.

These are the core truths that drive decision making at Affirm.

We are building a profitable enterprise built on our commitment to honest and transparent finance for everyone.

We are here to create products and services that deliver value. Value for our users, our merchants, our partners (e.g. banks that lend us money, which we lend to our users), and our shareholders, including every one of us.

We want to restore the original meaning of credit, which stands for “trust” and “belief.”

Take pride in what we do. Credit is an awesome tool for efficient use of capital. Like any power tool, it can be extremely useful, or dangerous when misused -- our job is to build products and services that offer the right balance of power and safeguards.

Our interests must remain aligned with our users and our partners: we will not profit off their misfortunes or mistakes.

A properly functioning financial system must have its “carrots and sticks”, but relying on users’ irresponsibility or forgetfulness for profits is not a sustainable way to create value.

We will work tirelessly to disclose our terms and conditions, in clear and transparent language, to help every user make an informed decision.

Hiding behind small print, "unspecified technical faults”, predatory same-as-cash debt-traps, and balloon interest schemes is not acceptable.

We make loans to those who we believe can pay us back, on time.

As we seek to align ourselves with the best interest of our users, we will not benefit from pushing someone into a state of permanent debt, or engage in predatory practices. And when we make an underwriting mistake, we will learn from it, and adjust our models as necessary instead of just "pricing in the loss.”

We enable purchasing of items that some people may see as essential, and others as indulgent. It is not for us to judge these purchases.

If we can responsibly underwrite a purchase a user wants, it is our job to do it. We have no right to tell someone what they should and should not have, only if we are willing to take the risk in helping them finance it.

We will dedicate money and time to helping educate members of our community in leading healthy financial lives.

Every successful startup requires a proper creation myth, a few embarrassing anecdotes punctuated by a poignant teaching moment or two. In the hands of an enterprising communications professional, a memorable origin story humanizes the founders, and preempts the perennial “how did it all begin” with a clever, if non-controversial, bromide. eBay’s PEZ dispenser sales, Google’s misspelling, Twitter inspired by taxi drivers’ short messages all come to mind. Are they exactly how things happened? Who cares, they are fun, and easy to retell.

Affirm is hardly at a point where a carefully crafted origin story is a requirement — it’s the sort of thing you focus on when it’s time for a coming-of-age cover story in a non-industry-specific rag. Nonetheless, here’s one from the pantheon of personal baggage contributing to my motivation towards this crazy goal of making consumer finance a more honest enterprise.

I was a Computer Science sophomore at the University of Illinois at Urbana Champaign when two wild and crazy guys named Luke and Scott (wild and crazy by the standards of the University's chapter of the Association of Computing Machinery, where we all met) interrupted my Mountain Dew-fueled bout of late-night programming at the ACM office (with no computer of my own, I took full advantage of school equipment) and proposed I stop wasting time on building neat graphics demos, and join them in an exciting startup adventure. I had no other plans for the evening, and so began my entrepreneurial journey.

The year was 1994, Mosaic Communications was just founded, and with the front-row seat to the Web supernova (the first graphical browser was built at UIUC by Marc Andreessen and friends) starting a company seemed like a great weekend project, because lack of a personal computer somehow still didn’t result in having much of a social life.

Fast-forward about a year, and our little startup (SponsorNet New Media — may it virtually rest in peace at the bottom of Huntington Towers in downtown Champaign, IL) was running out of cash. We burned through Scott’s reasonable, Luke’s meager, and my non-existent personal capital in the course of that year, and were now coming up towards the inevitable wall. Multiple fundraising forays proved futile, and our trivial earnings were not enough to keep the server lights on.

It was around that time that Scott pointed out that I had no credit cards. I was still the proverbial fresh-off-the-boat immigrant (we celebrated my 3rd anniversary in the U.S. that year) and had managed to avoid on-campus credit card pushers through sheer cluelessness. Luke and Scott, on the other hand, were doing a balance transfer every month or two, optimizing their minimum payments, and expanding their access to credit while satisfying our technology purchasing needs. And so I got my first credit card (and the obligatory free t-shirt) during the short walk between my dorm and the Digital Computing Lab.

As I rang up a sizable balance with my newfound source of cash flow, our startup, fueled in its last throes by that very cash, ran fully aground once and for all. My first startup was dead, long live my next startup. I took over the lease at Huntington Towers, planning to stay in Champaign and graduate, while Luke and Scott set off to the promised land of Palo Alto.

But even though Mercury, that fickle patron of entrepreneurs, totally flaked out on me (and would do so again and again) his credit was good with me. The twisty path of entrepreneurship was exciting, and I had complete faith that it led to some form of solvency. On the other hand, the good folks at the nameless issuing bank who were so thrilled to give me that $200 line of credit (and the t-shirt) weren't nearly as confident. Perhaps it was the few consecutively missed minimal payments, or my lack of immediate responsiveness to the incessant phone calls from their collection agents, but my limit was promptly reduced to $0, and my naive attempts at getting another card were all unceremoniously denied.

In 1995 I’d never heard the terms “FICO score” and “credit report”, and had an extremely vague idea of what happens when the largest minimum credit card payment one can afford is $0. By 1996 I was painfully aware of the consequences, and hard at work rebuilding my severely damaged credit score.  

Dreaming up world-conquering schemes in my spare time, I was doing less exciting, but lucrative, contract work, and paying down my credit card debt. By the time I graduated in 1997, I even had a small, but real win: one of my spare-time projects was acquired by a real Silicon Valley company. Either way, I was no longer in debt — the account was closed, the dreaded card finally cut up.

This is when I realized my troubles had just begun. Upon moving to Palo Alto soon after graduation, I couldn’t so much as get a cell phone — a friend had to cosign for me at the University Ave Sprint store, and for years caller IDs everywhere announced me as Eric, instead of Max. I slept on Scott’s floor in a 1BR in Palo Alto because no landlord would take me in with “that” credit score. Luke co-signed for my first car loan when Peter [Thiel] demanded I get my own wheels after getting tired of driving me around.

The embarrassments followed me around for years: having my new “repair-your-credit-by-paying-huge-interest” card declined on a first date, fielding suggestions to consider lesser apartments once I decided to move out of the hospitable floor I called home on Grant Ave. Every year or two, I would decide enough was enough, and I needed to do what I did best: reverse engineer the system that wouldn’t let go of my decade-old mistake, figure out the fastest path to fixing my FICO faux pas, and get the festering over with.

But there was always something more immediate to do, and the fine print on the statements (and the government info sites) detailing the path of the righteous man through the valley of FICO repair took too long to comprehend in one sitting. Over time, my financial blemishes finally became too distant, and the reactive shudder when hearing “I am just going to need to check your credit” became a mere muscle memory.

And so exactly 20 years after, nary a payment missed, telling an abridged version of this story to Affirm’s Risk Group, I once again got that familiar “oh no…” feeling when one of the guys offered to look up my current credit score. Honesty is a core value here at Affirm, and so I braced myself for the moment of truth. The answer came back quickly: 764.

Not bad, not amazing — I’d never qualify for Barclay’s Ring ultra-low 8% APR card (which reportedly requires FICO over 800!), but most banks would be motivated to extend me a pretty good offer of credit at this level. And so here’s that unglamorous, if real, origin story to be stashed away for future PR-department glamorization — it took me 20 years to almost clean up my credit score even though my financial irresponsibility spanned only few months.

I know I’m not the only one. Every day, recent immigrants are getting denied credit, young people are being persuaded into high-interest credit cards under the guise of 0% offers, and people’s financial lives are getting ruined because of one-time events like illnesses or layoffs. But it doesn’t need to be this way. That frustration and incredulity I had felt toward the credit scoring system remained in the back of my mind until the day when I had the time and resources to fix it.

When I was 14 or so, in 1989, I worked at the Advanced Communications Lab of Kiev's Communications College, a 2-year "technical professional” training school, at the time known by its Russian-language acronym KPTS. “Worked” in the sense that I talked the guy who ran the lab into giving me after-hours access to the various Soviet Bloc-made computing equipment (built mostly on East German and Russian clones of Intel and Zilog chips) in exchange for on-demand utility coding. Despite having some fairly advanced hardware (especially for late-'80s Soviet Ukraine), the lab had no actual software developers on staff, and having an extremely enthusiastic, if underaged, hacker around, ready to whip out an inventory tracker or unit converter, was apparently quite handy. Of course, to me there was little difference between “work" and "after-hours” — I got to write code, and that was all that mattered. I also got to play with fiber optic splicing, but that’s a different story. 

That spring, a coder friend of mine stopped by our little "PC room" to show me a “demo.” The room consisted of 6 shiny new ES-1842s — Soviet clones of 80286 XT (with stunning EGA color!). “Demos" used to be small pieces of carefully optimized code built specifically to showcase some unusual or unexpected functionality of the hardware at hand, and, by extension, the programming skill of its creator. I had no idea where my friend got it, but it sure wasn’t his work. 

As he hit Enter to launch the executable from the command line, I was stunned to hear a crackling but definitely digitally sampled human voice, wheezing out of the tiny PC speaker for the first time in my life. Though I was a fairly versatile coder, I wasn't at all aware of pulse-width modulation, and didn't think a desktop PC could make more interesting sounds than simple square wave tones. 

The clip crackling out of the speaker was just a couple seconds, looping words “forever… and ever… you stay in my heart…” while two colorful ASCII-art spirals swirled on the screen, the cursor flickering wildly in the top left corner, and rainbow strings of text fading in and out, sending “greets” from the author, to some faraway coders. 

The thought "computers are magical” rippled through my mind like a glorious 6-bit digital-to-analog shockwave, and my life was changed forever. I knew I wanted to make computers do magical things for the rest of my life. More importantly, I wanted to know who was the woman singing this magical song, of which I now knew but one line. 

A couple years later, as my family departed Soviet Union for the first and last time, I was politely “asked” to leave my wooden box with the treasure trove of 3” floppy disks in the hands of the customs agent in Moscow. The demo executable, which I kept around as a sentimental memento of my irrevocable commitment to all things nerdy, on its own special disk, was confiscated. 

I still had no information as to the identity of the magical singing woman, and who was it that she was keeping in her heart, forever and ever. With time, the acute curiosity faded, but the single-line sample looped in my memory often, a reminder of how it all became so clear to me. Even after the public web became the repository of all knowledge, I simply hadn’t thought to Google her, or perhaps the worry of blowing up the magical memory bubble somehow kept me from looking her up.

Nearly 30 years later, I walked into what one might consider a serviceable coffee shop in San Francisco’s Financial District, and heard her. No announcement, no fair warning, I walked in for a cup of drip, and there she was, just forever- and ever-ing away, like three decades were nothing. Without much time to waste on remembrances of things past, I got to Shazam in six taps and that very same magic was back, but the mystery was over: Aretha Franklin, I Say A Little Prayer. 

Spotify had dozens of renditions, including the Dionne Warwick 1967 original, and for the next 24 hours my reminiscence was in its highest gear. Undoubtedly, the two people following my playback stream on Spotify were somewhat surprised to see exactly one soul track on repeat, but magic and I had a lot of catching up to do. 

Except, I knew it was not the right song. Or rather, the song was right, but the rendition wasn’t — though the track I heard was certainly muddled by the hardware never meant to do more than simple bleeps, I could tell this wasn’t it. The magical woman was singing the right words, but I knew she never peddled psychic friendships, nor was she The Queen of Soul herself. 

So, a day after, while driving (I know, I know), between three stop lights, I once again used my phone to resolve the last bit of the mystery. After two searches, Google uncovered the name which sent warm waves of memory through my head: atom.exe, some then-kid hacker’s summer project — a demo he coded on his own. I certainly coded plenty of those in the decade after atom.exe and I first met, though not so much lately. 

It was like looking back at my barely-teenaged self, except this time I was literally looking at it: playing happily on my phone, streaming via an LTE network, near-perfectly reproducing both the text-mode video, cursor flicker and all, as well as the cranky audio, was a YouTube video of the original, captured right off someone’s undoubtedly collector’s-item PC. And right there, in the comments, there she was, the singer credited: Maureen Walsh, covering Dionne’s ditty (and/or Aretha’s anthem) in the first Bomb The Bass disc from 1988. 

This is the approximate text of the keynote I gave at DLD13 today in Munich. I felt my delivery of this (admittedly, relatively dense) material was not the best, but the content is crucially important. To that end, I am posting the notes here. They were edited for grammar beyond the basics, so you will have to forgive the occasional fifth-grade prose.

----------

Many of today's big data companies are trying to tackle problems that just aren't nearly big enough. 

Most are focused on marginally improving existing, digital businesses, but I believe the next big wave of opportunities exists in centralized processing of data gathered from primarily analog systems.

At PayPal, where I was the CTO, we succeeded because we gained deep understanding of the immense quantities of behavioral data that we captured in processing millions of transactions per day. We learned so much about our customers, that we could predict their intentions, and prevent vast majority of intentional fraud. 

At HVF, the project I began in 2011, we seek to create businesses that improve the analog, real world through deep understanding of data. I will tell you more about that in a bit, but first let me expand on what I mean by "digital sensors over analog data."

Collaborative consumption is a huge current trend. To me, it started to make sense with Über -- idling black limo cars put to better use. Über (where I am now an investor) created a simple piece of software to send the idle ones to price-insensitive consumers in need of a cab with a bit of flair. 

The world of real things is very inefficient: slack resources are abundant, so are the companies trying to rationalize their use. Über, AirBnB, Exec, GetAround, PostMates, ZipCar, Cherry, Housefed, Skyara, ToolSpinner, Snapgoods, Vayable, Swifto…it's an explosion! What enabled this? Why now? It's not like we suddenly have a larger surplus of black cars than ever before.

Examine the DNA of these businesses: resource availability and demand requests -- highly analog, as this is about cars, drivers, and passengers -- is captured at the edge, automatically where possible, then transmitted and stored, then processed centrally. Requests are queued at the smart center, and a marketplace/auction is used to allocate them, matches are made and feedback is given in real time. 

Utilization per dollar goes up, because there is simply less idle time! So efficient is this new approach in fact that limo companies started hiring drivers to drive for Über only.  

I am ignoring some key details, like the need for mutual trust between participants that is at least initially enabled by the presence of a trusted third party, and the feedback loop from consumers of the service, but at its core, these business all look very similar.

A key revolutionary insight here is not that the market-based distribution of resources is a great idea -- it is the digitalization of analog data, and its management in a centralized queue to create amazing new efficiencies.

Consider the cab calling experience vs Über. When dialing up a cab, you are managing your own spot in the queue. If you hang up in anger, you go back to the end. If you stay on, listening to the on-call tune, you may be an infinite loop, as there is no feedback! 

And even if you are willing to pay a hundred times more than everyone else waiting ahead of you in line to speak to dispatch, you never get to express that demand. The data exists in an analog-only format, and it moves at analog-only speeds.

With Über, the queue can be managed centrally (because the information is converted to a digital format at the edge) with nearly complete transparency to you -- you know when the resources you want become available, you know how long you have to wait for them, and most importantly, you are generally assured through feedback that you have not been forgotten or ignored.

So why is all this now? Cheap digital sensors over analog resources (cars, houses, humans, etc) -- AT&T pays for your GPS... so you'd consume more data of course. Mobile broadband, of course. Even more key is the critical mass of pretty smart devices that are clients for real-time participation in queue management with feedback. It's the smart-enough terminal model. 

As an aside, consumers want sexy sensors that give visual feedback to motivate action (and more data) -- like the Nike Fuel band. Machines, on the other hand, just want cheap sensors to get more data from.

I sometimes imagine the low-use troughs of sinusoidal curves utilization of all these analog resources being pulled up, filling up with happy digital usage. 

Private jets spend 1h per day on average in the air. BlackJet promises to make that number closer to the commercial average -- 10h/day. And not everyone in a suburban neighborhood needs their own lawn mower -- they need an app to schedule one of the local kids to come by and take care of their overgrown grass. 

The defensibility of these businesses lies in their ability to build a network effect -- a network effect of data. Once a business understands substantially more than any one of the resources managed in their queue, it's effectively impossible to compete with them on price -- they can always see more of the usage as it happens, and price it more efficiently, pushing any competition out. 

So what other businesses can we expect to emerge in analog-data-driven, central-intelligence queue marketplace businesses? Some interesting ones are probably already being built: a market for private neighborhood security (off-duty cops)? An auction for short-term patent licenses (litigator included)? Technology already enables efficient redistribution for your spare change: it's Kickstarter and AngelList. We will definitely see dynamically-priced queues for confession-taking priests, and therapists!

How about dynamic pricing for brain cycles? We have been maximizing utilization of very high-value, very low-frequency specialists -- today you can already rent the brain of a data-mining genius via Kaggle by the hour, tomorrow by brain-hour. Just like the SETI@Home screensaver "steals" CPU cycles to sift through cosmic radio noise for alien voices, your brain plug firmware will earn you a little extra cash while you sleep, by being remotely programmed to solve hard problems, like factoring products of large primes.

There is also a neat symmetry to this analog-to-digtail transformation -- enabling centralization of unique analog capacities. As soon as the general public is ready for it, many things handled by a human at the edge of consumption will be controlled by the best currently available human at the center of the system, real time sensors bringing the necessary data to them in real time. The freshest, smartest pilot, most familiar with the particular complicated airport will land your plane -- via remote control.   

So what's after that? This is where it gets really interesting. These new modes of operation -- remote controlled cars and planes flown by pilots you can't see, rides in quasi-cabs with people you have never met, legal advice from lawyers whose license you cannot really check. This is going to add a huge amount of new kinds of risks. 

But as a species, we simply must take these risks, to continue advancing, to use all available resources to their maximum. Yet these risks are real, and they cannot be ignored.

The way to deal with risk is of course some form of insurance. Modeling loss from observed past events is hardly news, but dynamically changing the price of the service to reflect individual risk is a big deal. My expectation is that next decade we will see an explosion of insurance and insurance-like products and services -- leveraging those very same network effects of data, providing truly dynamic resource pricing and allocation. 

This is the purpose of my new project, HVF -- to bring these new products to those that will benefit from them the most. We see data-driven understanding and pricing of risk as the great opportunity to improve lives. The reason the notion of analog is so important here is because it ultimately also means "human."

Understanding the changing risk profile of a person can deliver to them amazing opportunities they wouldn't have in today's world: inferring that a particular college grad is financially responsible by looking at their tweets could allow them to buy their first house on credit, at 21, without any history, and looking at someone's heart rate monitor data could make their cardiovascular healthcare cost-free. 

These are not non-controversial topics -- privacy, unfair discrimination, built-in biases are all possible, and we must be thoughtful and diligent in how we go about bringing this future. But I believe that what we can enable with data insights greatly outweighs the downsides. 

Here is what I mean, by way of a simple example.

On a Sat morning, I load my two toddlers into their respective child seats, and my car's in-wheel strain gauges detect the weight difference and reports that the kids are with me in a moving vehicle to my insurance via a secure message through my iPhone. The insurance company duly increases today's premium by a few dollars. 

My keepHonest app sees this too and immediately offers me up as a customer to a few competing insurance companies in the background, but nobody is willing to charge me less right now, and the phone chirps sadly to let me know I'm now paying a higher premium. Safer, but more expensive. 

But In a few hours, my car's GPS duly reports to my insurer that I only drove two miles to the park, never sped and, and observed all traffic signs. My phone now chirps happily: not only has my rate been discounted, several companies are offering me a deal on insurance!

As announced by Yahoo! this morning, I have been asked and agreed to join its Board of Directors. It is an honor to be asked, in and of itself. There are three key reasons I accepted:  

Personal: I've long respected Marissa's talent and tenacity. Her decision to take the top role at Yahoo! was a very ballsy move, and when she asked for my help, I was excited about working with her. 

Business: a stronger, fast-growing  Yahoo!, with its tremendous resources is a massive net-positive for the Silicon Valley ecosystem, the market in general, and the US economy. 

If you are ever going to start a company or work at a startup, do it now, while you are still young. I do not agree with the conventional wisdom that startups are for young people only, that once you get past a certain age it's all over -- in my late thirties, with two kids, a dog, and an Audi, I better not. Helping start up and build companies is something I intend to do well into the afterlife.

But I do think the fact that I started my first entrepreneurial venture a few years before I was legal to drink (or had anything to lose) created the brain patterns and adaptations necessary to cope with the stress of starting and running a company. It was a bit like getting beat up the first day of school and losing all fear of bullies -- it hurts, but you know what the worst is like.

I simplistically divide people into two broad top-level categories: boring people -- not very thoughtful, interesting, smart, talented, etc, and fascinating people -- very smart, insightful, knowledgeable, talented, etc. The latter category has a very special sub-category that I am truly enthralled by: the high-leverage people. 

I define them as people who act on their big ideas. They are capable of articulating a theory of how the world works today and how it should change, and then proceed to actually change the world, or at least attempt to. They are the people that can describe big changes that impact major swaths of humanity (we will privatize space flight! we will sequence the human genome! we will find safe alternative to oil! etc), and then actually proceed to replace "we" with "I" through their actions, be it entrepreneurship or investing or volunteering. Lecturing the world about how it will become a better place is the domain of big thinkers: brilliant, influential, but ultimately theoretical. Those that bring the big ideas into hard, unpredictable reality are the practitioners, the high-leverage ones, and I admire them almost without reservation.

One key ingredient of being this kind of a person is an almost irrational lack of fear of failure and irrational optimism, but there is a more tactical side there too: they manage to not get caught up in all the little details,.. while being remarkably aware of the really important ones. 

There must be many more essential ingredients to being high-leverage. I'd love to understand this type of person better.... so I can maximize my own leverage.