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.
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, 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)
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!
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 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:
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:
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:
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.
