CoopCycle is a federation of bike delivery co-ops,
currently in 44 cities.
I’m intrigued about this space because I’ve been thinking about last-mile delivery: e-commerce is great, but it has a tendency to (a) centralise, and (b) squash delivery workers.
So by breaking “delivery” out as a separate layer in the stack, maybe it would be possible for my neighbourhood shops and restaurants to plug in to a system of e-commerce that favours localism and community (rather than have to go via singular food and retail apps that capture the audience, and then replace the local spots with dark kitchens and commodity merchants). That’s the hypothesis anyway.
But I’m particularly attracted by the CoopCycle model.
CoopCycle is software:
It includes maps and fleet management, for dispatch to receive tasks and manage couriers. It takes platforms. It has API integrations to accept delivery tasks from e-commerce software.
Each city is a separate co-operative of bike couriers, who together decide to use an instance of the software.
I was going on about self-driving corporations recently and this is exactly what I meant: usually companies have human managers and business people, and the actual labour (the operations) are employees – or, increasingly, outsourced and treated as replaceable component parts. The idea of the self-driving corporation is to flip that model on its head: a company can be a collective of the people who contribute the skilled work, and the business management is the layer that is automated away.
Here’s another way of thinking about it, going back to the enormously useful formulation by Peter Reinhardt (Segment CEO) of “Below the API” jobs in his 2015 article Replacing Middle Management with APIs.
Reinhardt starts by showing that Uber drivers are dispatched by a call in the code, and asks, What does that make the drivers? Cogs in a giant automated dispatching machine, controlled through clever programming optimizations like surge pricing?
Then he points out the inevitable: economic incentives will push Above the API engineers to automate the jobs Below the API: self-driving cars and drone delivery are certainly on the way.
A more succinct way of putting it, from Tom Preston-Warner (GitHub founder):
“In the future there’s potentially two types of jobs: where you tell a machine what to do, programming a computer, or a machine is going to tell you what to do,” he says. “You’re either the one that creates the automation or you’re getting automated.”
The question is, does CoopCycle provide a clue in how to subvert the inevitability of the “Below the API” logic? I think it does. Here’s where I would start.
Food delivery apps keep up the pretence that their delivery drivers and couriers are “independent contractors.”
What if, by regulation, we said that it’s fine to have these below the API jobs – but you must open up the API to other bidders.
So, yes, they can dispatch a job to random local bike courier… but they must also offer that job to whoever else might take it, such as the local software-enabled courier co-operative. Using the same APIs, of course, but open and documented.
Insisting on higher wages, and unencumbered by the margin usually extracted by management (which has been automated), the co-op would snap up all the local independent couriers, effectively unionising neighbourhood delivery services. As a collective, they’re able to push back on the downward pressure on wages when the couriers are atomised.
The food delivery app would have no choice but to operate through them, bike couriers who are still independent yet have leverage to retain strong rights and benefits. It’s not quite mutualism (where the couriers would share in the success of the delivery company), but perhaps this would still represent a new class of worker.
Some questions to finish up.
Is the regulatory intervention I describe above even possible? Can the concept of “Below the API” jobs be flipped against itself, the companies above the API forced to open up? That is, can the pressure to automate jobs into non-existence be reversed?
A counterpoint: the risk of keeping delivery costs high is that it accelerates the adoption of automated delivery solutions, putting people out of work even faster! But I regard that as a separate problem. Let’s solve for the downward pressure on wages/rights first, and then look at how humans and automation compete.
Final question. What other types of organisation are tractable to CoopCycle’s approach of self-driving software co-operatives?
CoopCycle is currently in 44 cities.
I’m intrigued about this space because I’ve been thinking about last-mile delivery: e-commerce is great, but it has a tendency to (a) centralise, and (b) squash delivery workers.
So by breaking “delivery” out as a separate layer in the stack, maybe it would be possible for my neighbourhood shops and restaurants to plug in to a system of e-commerce that favours localism and community (rather than have to go via singular food and retail apps that capture the audience, and then replace the local spots with dark kitchens and commodity merchants). That’s the hypothesis anyway.
But I’m particularly attracted by the CoopCycle model.
CoopCycle is software:
It includes maps and fleet management, for dispatch to receive tasks and manage couriers. It takes platforms. It has API integrations to accept delivery tasks from e-commerce software.
Each city is a separate co-operative of bike couriers, who together decide to use an instance of the software.
I was going on about self-driving corporations recently and this is exactly what I meant: usually companies have human managers and business people, and the actual labour (the operations) are employees – or, increasingly, outsourced and treated as replaceable component parts. The idea of the self-driving corporation is to flip that model on its head: a company can be a collective of the people who contribute the skilled work, and the business management is the layer that is automated away.
Here’s another way of thinking about it, going back to the enormously useful formulation by Peter Reinhardt (Segment CEO) of “Below the API” jobs in his 2015 article Replacing Middle Management with APIs.
Reinhardt starts by showing that Uber drivers are dispatched by a call in the code, and asks,
Then he points out the inevitable:
A more succinct way of putting it, from Tom Preston-Warner (GitHub founder):
The question is, does CoopCycle provide a clue in how to subvert the inevitability of the “Below the API” logic? I think it does. Here’s where I would start.
Food delivery apps keep up the pretence that their delivery drivers and couriers are “independent contractors.”
What if, by regulation, we said that it’s fine to have these below the API jobs – but you must open up the API to other bidders.
So, yes, they can dispatch a job to random local bike courier… but they must also offer that job to whoever else might take it, such as the local software-enabled courier co-operative. Using the same APIs, of course, but open and documented.
Insisting on higher wages, and unencumbered by the margin usually extracted by management (which has been automated), the co-op would snap up all the local independent couriers, effectively unionising neighbourhood delivery services. As a collective, they’re able to push back on the downward pressure on wages when the couriers are atomised.
The food delivery app would have no choice but to operate through them, bike couriers who are still independent yet have leverage to retain strong rights and benefits. It’s not quite mutualism (where the couriers would share in the success of the delivery company), but perhaps this would still represent a new class of worker.
Some questions to finish up.
Is the regulatory intervention I describe above even possible? Can the concept of “Below the API” jobs be flipped against itself, the companies above the API forced to open up? That is, can the pressure to automate jobs into non-existence be reversed?
A counterpoint: the risk of keeping delivery costs high is that it accelerates the adoption of automated delivery solutions, putting people out of work even faster! But I regard that as a separate problem. Let’s solve for the downward pressure on wages/rights first, and then look at how humans and automation compete.
Final question. What other types of organisation are tractable to CoopCycle’s approach of self-driving software co-operatives?