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 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:
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,
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 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:
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,
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!
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!
Share Dialog
Share Dialog
Share Dialog
Share Dialog
Share Dialog
Share Dialog
