As Massachusetts ponders ride-sharing regs, where’s the data?

Today, hearings begin at the Massachusetts state house over how to regulate the budding ride-sharing / on-demand transportation industry (Uber, Lyft, et al).

Adam Vaccaro over at Boston.com has a good summary of the various competing bills — a pro-Uber bill that welcomes new Transportation Network Companies (TNCs) with relatively light-touch regulation, and a pro-taxi industry bill that makes it harder for TNCs to operate.

As I’ve written about before, I think the emergence of ride sharing, on-demand, TNCs is a good thing.  It makes getting around the city easier and safer, and it provides a flexible opportunity for work.  And, as cities ponder how to regulate them, they need to think differently — looking at the data-driven trust and safety techniques the TNCs bring to bear as a “regulatory innovation” rather than a threat to traditional law & order.

I call it “regulation 2.0” – thinking about public sector regulation the same way platforms (uber, etsy, airbnb, ebay, etc) think about “trust and safety”, by loosening up-front requirements for participation in exchange for data-driven accountability:

moving from this:

Platform-Gov-regulations.004

to this:

Platform-Gov-regulations.005

So, looking at Massachusetts, what’s the one thing missing from any of the proposals?  Data.

The proposals cover important issues like insurance and passenger safety, and largely differ on how easy it is for platforms and drivers to get started.  But none of them make any mention of the data being generated by these platforms, why it matters, and what it can be used for.

I recently spoke with someone in the NYC Mayor’s office about their ongoing efforts to understand the impact of TNCs on the city, and to regulate appropriately.  As a refresher, NYC recently dropped their bid to regulate the supply of Uber drivers and instead opted to study the impacts of TNCs on city traffic.

It became clear to me that the city is basing its regulatory decisions on very little data.  The Department of Transportation doesn’t have reliable, standardized, longitudinal data, the Taxi & Limousine Commission (the taxi industry’s regulator) doesn’t keep usable data, the city doesn’t have partnerships with other transportation data networks (for example, Google/Waze, Verizon, AT&T, etc).

My argument, then, is that a primary point of negotiation between cities and TNCs (and any other web/mobile powered network that intersects with regulated aspects of the city — food, housing, etc) should be about access to data.  For web/mobile platforms, data is a huge asset, yet for cities it’s not even on the table.

Of course, this has to be a trade.  No platform would be willing to share performance data without a proper incentive.  And my point is that the incentive should be fewer traditional regulations, and more freedom to operate, in exchange for data sharing.

Further, data negotiated by cities in these situations should be available publicly, to enable independent analysis by third parties.  Not only do cities not have the internal capacity to analyze such data, but they also want any conclusions they draw to be verifiable and peer-reviewable.  Just like science.  So that, if and when they do decide to enforce regulations, they have a leg to stand on

One saving grace is that this conversation is happening over and over again in cities across the world, so we’ll see many permutations of solutions and outcomes, and hopefully some cities will start to get it right and get the best of both worlds: more competition, more experimentation.  Less regulation, more data.  Better transportation and safer, more convenient cities.

Introducing Quackpad – simple collaborative docs for teams using Slack

Every month at USV we have an internal hack day, where we work on various fun tech projects.  We hack on USV.com, we build internal tools, we play with fun new hardware, try out new APIs, etc.  It’s a nice change of pace, and an opportunity to get a little closer to the tech we spend most of the time talking about.

One area we’ve spent some time on recently is building tools for the USV Network.  We have about 60 active portfolio companies, and it’s Brittany‘s job to help them learn from each other as much as possible.  She’s the human router within the portfolio, matching up skills, questions, needs, and experiences.  As part of that, she runs over 50 peer-driven summits ever year across functions (engineering, mobile, people, trust & safety, etc), where members from each company come together to talk shop.

Each summit produces a long list of notes, follow-ups, questions, contact info, etc.  One persistent problem has been making that document accessible, hackable and shareable, both during the summits and afterwards.  Version 1 was a google doc later ported into a Yammer document for archiving.  We recently moved the portfolio network from Yammer to Slack, where we are now approaching 1000 members.  As part of that, we decided to see if we couldn’t hack something together using the Slack API to easily share docs across this large and diverse group.

Last Hack Day, we built a “login with Slack” workflow into USV.com, and created a simple CMS for group-editable documents using Firepad (an excellent open source collaborative document engine built on Firebase).  After doing that, we realized that it would be just as easy to open this up to anyone, regardless of their Slack team, and the result is Quackpad:

Screen Shot 2015-07-30 at 9.08.03 AM

It’s very simple: go to Quackpad.io and sign in using your Slack account.  You can create a simple group document that’s immediately shareable with anyone else who is a member of that Slack team (and not to anyone else).

It’s particularly good for Slack teams made up of people from across organizations, who wouldn’t otherwise have an easy way of sharing docs privately (vs., say, a company, where everyone is on gApps).

This is alpha software!  So use at your own risk and let Brittany and me know if you run into any trouble.

Big props to: Michael Lehenbauer from Firebase, the primary author of Firepad, the whole USV team and network for helping build this and test it, and Slack for having a really nice API to work with.

Enjoy!  (and vote it up on Product Hunt!)

Supporting workers in the gig economy

If there’s one thing I’ve learned throughout my years as a human, it’s that life is hard and people need help in order to make things work.

That help can come in many forms: family, friends, co-workers, teachers, unions, healthcare providers, agents, assistants, coaches, therapists, strangers on the internet, you name it.  Point is, we all need it, and good help can be hard to find (assuming we get over the first hump and even start to look).

I’ve been spending a lot of time recently looking at this problem in a particular use case: the rise of the independent worker.

As I mentioned in a post last year, I’ve been interviewed a lot about the emergence of the “sharing” or “on-demand” economy (Fastco, Wired, NY Times, PBS Newshour) and the question always comes up is: “aren’t all of these new independent workers missing out on the stability provided by full-time employment?”  Albert describes this as the unbundling of the job — splitting apart the support systems that had traditionally been associated with full-time work (salary, benefits, community, training, etc) and leaving workers to fend for themselves.

In the past few months, this issue has come to even more of a head, with the Lyft/Uber class action suits seeking W2 status for on-demand drivers, the California Labor Commission decision that (in a single case) an Uber driver could be considered a W2 employee and not an independent contractor, and moves by other on-demand platforms move some or all workers from a 1099 model to a W2 model, as Shyp and Instacart recently did.

A year ago, when I started speaking to reporters about this, my consistent answer was that we hope to see a new layer of networked services emerge that will fill the gaps left by the unbundling of the job, that start to solve workers’ issues in creative new ways.

And conversely, what I hope we don’t see is a knee-jerk attempt to shoehorn today’s independent, networked workers into the old paradigm of full-time single employer work, throwing the baby out with the bathwater.

Sherpashare recently did a study of on-demand drivers, asking them what they like and don’t like about this new model of work.  Not surprisingly, they love the flexibility and freedom that comes with (semi) independent, networked working lifestyle.  But they also want more control over their work, chafing at the level of control that many of the services-oriented (vs. marketplace-oriented) platforms exert.  That makes sense to me.   There’s also an obvious need to basic support tools and services (for example around finance and insurance/benefits).

Now, a year later, many these kinds of services have indeed begun to emerge.  Over the past several months, I’ve spoken to many entrepreneurs approaching this problem, from a bunch of different directions.  Here is my latest snapshot of how that market looks today:

Screen Shot 2015-07-28 at 11.42.08 AM (2)

Nearly all of these are brand new. Many of them are pre launch, and many of those are just at the idea phase.  And, as you’d expect, they are all tackling different facets of the problem.

Here’s a quick review of the categories I’ve been tracking:

Job Discovery: gotta find work, and there are an increasing number of competing options out there. Matching those opportunities to workers will be important.  (see: Dispatcher, Opus for Work, BlueCrew)

Education & Training: along with the unbundling of the job comes, to some extent, the unbundling of education & job training.  The need here spans both sector-specific training and more general education like financial management. (see: Peers, KungFu)

Community: as workers become more independent, we will need new ways to form various forms of community support, from commiserating, to peer-learning, to organizing. (see: Coworker, Domino, Sherpashare)

Equipment: gotta have the tools and the space to do the job. (see: CoPass, Breather, ReCharge, IdleCars, Breeze)

Admin: keeping track of your finances, expenses and taxes as an independent worker totally sucks.  April 15th is doomsday.  There are a bunch of tools providing helpful services here.  (see Zen99, Benny, Hurdlr, And Co)

Banking: money is at the center of everything, and independent workers have unique financial needs, in particular related to lumpy cash flow, saving for taxes, and overdraft & lending.  (see: Even)

Benefits & Insurance: clearly a huge issue, relating to everything from healthcare, to disability, to liability, to operating insurance. Traditional insurance plans aren’t built for this economy, and insurance will be a huge part of continuing to build trust, safety and security in this sector.  (see: Stride Health, Freelancers Union)

Identity & Reputation: perhaps the biggest opportunity, in my view. As independent workers work across platforms and services, reputation is their currency.  Platforms are built on trust, and workers need to be able to port that trust from one context to another.  Unclear how we will get to a world where workers control their identity and reputation data — could be indirectly, through banking, insurance, or job discovery.  (see: Opus.me, Karma, Traity, Checkr)

This is surely incomplete, and many of the examples span categories, but it’s a start.

The happy confluence

There will undoubtedly be many tensions as this market develops, particular around the sharing and control of data (for example, worker-facing APIs and the right to be represented by a bot).  There is, however, a nice potential synergy between the needs of work platforms and worker support platforms.  In order for work platforms to maintain the arms-length relationship with worker/partner/contractors required for proper 1099 status, they will necessarily need to relinquish some amount of control, which could really open up the market here.  We will see.

Finally: if you are working on this, I want to know you!

Pain x Resistance = Suffering (the case for throughput)

For the past nine months or so, I’ve been seeing a therapist specializing in mindfulness. Perhaps the best decision I’ve ever made.

One of the things we spend a lot of time talking about is resistance – everyone has their own quirks and issues, and that’s one of mine.  The tendency to hit the brakes when faced with something difficult or unpleasant.  Set it to the side, avoid, wait.  Obviously, this is a bad tendency, and only serves to make things worse.

One idea that has come up is the relationship between resistance and suffering. Suffering is the ultimate mindstate we are looking to avoid.  There’s this equation which has really stuck with me :

Pain x Resistance = Suffering

In other words, it is possible (and typical) to start with a relatively painless situation and then amp it up, and multiply the ultimate suffering by resisting it.

I can’t tell you the number of things in my life that I have resisted and avoided which then ultimately ended up being no big deal. And the ultimate suffering was more a result of the resistance the the pain itself.

The mindfulness approach to resistance is to instead turn and face whatever thing your avoiding. Just recognize it and be with it. I’ve thought of this before as “living in the fall line“.  The opposite of living in a mode of resistance.

Another way of thinking about it is as throughput. Moving items (projects, emails, bills, whatever) through, rather than letting them like up. Resistance is like arterial plaque. Throughput is the result of keeping things healthy and flowing.

It’s a good feeling.

Here’s the solution to the Uber and Airbnb problems — and no one will like it

It’s been a fascinating week to watch the war between Uber and the De Blasio administration play out.

Not surprisingly, Uber ended up carrying the day using a combination of its dedicated user base and its sophisticated political machine.

This is yet another very early round in what will be a long and hard war — not just between Uber and NYC, or Uber and other cities, but between every high-growth startup innovating in a regulated sector and every regulator and lawmaker overseeing those sectors.

Watching the big battles that have played out so far — in particular around Uber and Airbnb — we’ve seen the same pattern several times over: new startup delivers a creative and delightful new service which breaks the old rules, ignoring those rules until they have critical mass of happy customers; regulators and incumbents respond by trying to shut down the new innovation; startups and their happy users rain hellfire on the regulators; questions arise about the actual impact of the new innovation; a tiny amount of data is shared to settle the dispute.  Rinse and repeat, over and over.

I am not sure there’s a near term alternative to this process — new ways of doing things will never see the light of day if step 1 is always “ask permission”.  The answer will nearly always be no, and new ideas won’t have a chance to prove themselves.

Luckily, though, we have somewhat of a model to follow for a better future.  It’s the way that these new platforms are regulating themselves.  My colleague Brad has long said that web platforms are like governments, and that’s becoming clearer by the day (just look at Reddit for the latest chapter).

The primary innovation that modern web platforms have created is, essentially, how to regulate, adaptively, at scale.  Using tons and tons of real-time data as their primary tool, they’ve inverted the regulatory model.  Rather than seek onerous up-front permission to onboard, users onboard easily, but are then held to strict accountability through the data about their actions:

Platform-Gov-regulations.002

Contrast this with the traditional regulatory model — the one government uses to regulate the private sector, and it’s the opposite — regulations focus on up-front permission as the primary tool:

Platform-Gov-regulations.004

The reason for this makes lots of sense: when today’s regulations were designed (largely at the beginning of the progressive era in the early 20th century), we didn’t have access to real-time data.  So the only feasible approach was to build high barriers to entry.

Today, things are different.  We have data, lots of it.   In the case of the relationship between web platforms (companies) and their users, we are leveraging that data to introduce a regulatory regime of data-driven accountability.  Just ask any Uber driver what their chief complaint is, and you’ll likely hear that they can get booted off the platform for poor performance, very quickly.

Now, the question is: how can we transform our public regulations to adopt this kind of model?  Here’s the part that no one will like:

1) Regulators need to accept a new model where they focus less on making it hard for people to get started.  That means things relaxing licensing requirements (for example, all the states working on Bitcoin licensing right now) and increase the freedom to operate.  This is critical for experimentation and innovation.

2) In exchange for that freedom to operate, companies will need to share data with regulators — un-massaged, and in real time, just like their users do with them.  AND, will need to accept that that data may result in forms of accountability.  For example, we should give ourselves the opportunity to enjoy the obvious benefits of the Ubers and Airbnbs of the world, but also recognize that Uber could be making NYC traffic worse, and Airbnb could be making SF housing affordability worse.

In other words, grant companies the freedoms they grant their users, but also bring the same data-driven accountability:

Platform-Gov-regulations.005

That is going to be a tough pill to swallow, on both sides, so I’m not sure how we get there.  But I believe that if we’re honest with ourselves, we will recognize that the approach to regulation that web platforms have brought to their users is an innovation in its own right, and is one that we should aim to apply to the public layer.

Over at TechCrunch, Kim-Mai Cutler has been exploring this idea in depth. In her article today, she rightly points out that “Those decisions are tough if no one trusts each other” — platforms (rightly) don’t trust regulators not to instinctively clamp down on new innovations, and regulators don’t trust platforms to EITHER play by the existing rules OR provide in-depth data for the sake of accountability.

In the meantime, we’ll get to observe more battles as the war wages on.

Brutal honesty delivered kindly

On my way to SF this week, I stopped over in Boulder, visited Techstars and then had dinner with Brad Feld, where got to talking about the dynamics inside and around venture firms.  He has obviously been doing this for a long time, and for me, less of a long time (3-1/2 yrs at this point).

I was remarking about the working dynamic at USV, and in particular the way — that I’ve never experienced before at another workplace — that we are able to have pretty serious conversations about a lot of complex issues, including divergent opinions, and yet still do it in a way that is shockingly respectful and seemingly apolitical.  I give the USV team a whole lot of credit for being able to work this way, and it’s really a joy to be around.

Same goes for the dynamics I witness between partners and founders.  We deal with a lot of hard shit — something, somewhere is often badly broken and requires hard choices as well as creative and tough deal making — and getting to the bottom of it means staring it in the face.

Another way of saying both of those things is that I’ve been impressed by the way folks on our team are able to be tough and smart but also kind.  And the more I see difficult situations come and go the more I appreciate the importance of empathy in this business.  It’s fucking  hard and stressful and things break and go wrong all the time, and that’s just the way it is.  And getting through that — either succeeding, failing or some combination of both — takes a combination of brain and heart.

Brad said that he and his partners have a mantra for how they think about this: brutal honesty delivered kindly.  No dodging or glossing over problems and challenges, but also no being a dick.

I like that way of thinking about it.

The Blockchain as verified public timestamps

Two weeks ago at USV’s annual CEO Summit, Muneeb Ali from OneName explained the blockchain in a way I hadn’t heard before, and which I thought was really helpful: the blockchain is time.

That’s a somewhat abstract way of saying it, so more concretely we could say that:

The blockchain is database of verified public timestamps.

Every bitcoin transaction is kept in a public ledger, and that ledger is verified and maintained by all of the computers participating in the Bitcoin network.  This “chain” of transactions is known as the blockchain, and each transaction is essentially a public timestamp that can contain data.

The key aspects of the blockchain’s timestamps are: decentralized (no one entity controls the database of timestamps, and everyone in the network confirms that timestamp has happened — this is “mining”), immutable (once a timestamp has been verified and recorded, you can’t un-do it), public (all of the timestamps are publicly visible, though some aspects of the data are encrypted), and programmable (you can write code against the blockchain — for example, triggering some sort of action based on the details of a “smart contract” embedded in a timestamp).

Importantly, each of those timestamps contains a packet of data which can hold lots of things: details about a financial transaction, details about a contract between two or more parties, a hashed version of almost any document, etc.

One way I’ve described this is similar to the way people used to use postmarked envelopes to verify that something had happened at a certain time.  For example, signing a will and putting it in an envelope, and mailing it to yourself — the post office’s postmark on the envelope, which has the date of the stamp, proves that whatever was put in the envelope was done so before the date of the stamp.  IIRC, more than once, a mystery on Colombo was resolved using this technique, where a witness dramatically unseals a postmarked envelope before the judge.

The blockchain is essentially a digital, public, programmable version of that.  Which we’ve never had before.

Previously, every app kept its own notion of time. So if I post something on Facebook, Facebook saves that post and timestamps it.  We have to trust them to get that right, and not to change it ever in the future.  This is fine for cat photos, but less fine for a financial transaction, or a deed to a house.

Here’s that same idea in diagram form:

Screen Shot 2015-06-17 at 10.13.03 AM

So in some sense, the Blockchain is a public database — it has the effect of moving data that was previously kept within the walls of one or more apps out into a shared public database.   But to get a little more specific, it’s really a public database of timestamps — a new ability for anyone to state, publicly and immutably, that a certain thing happened at a certain time.

Maybe that is obvious to folks who have been working in this space for a while, but I found it to be a really helpful way of thinking about things — and of explaining it to people who are new to the idea.  Thanks Muneeb!