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:
to this:
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.
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
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:
to this:
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.
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
'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
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!)
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:
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
'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
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!)
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:
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
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
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:
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:
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:
) 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
). 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!
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
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:
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:
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:
) 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
). 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!
