- In car-oriented areas, it's very unlikely that a standard car insurance policy would permit commercial use like this. If employees end up in a crash, and it is discovered that they were performing a delivery their claim may be denied. This seems like a compliance and liability nightmare.
- In urban areas where bikes are preferred, employees may or may not have one, but it's very possible they won't have one that is appropriate for delivery. Also, woe on Doordash when the first $500k+ TC SWE gets doored and puts in a worker's comp claim.
The actual deliverers are contractors, so it is reasonable to expect them to provide their own equipment: a car with proper commercial insurance, or a bike that can be locked outside safely. That's part of being a contractor. It is not reasonable whatsoever to expect FTEs to use their own equipment to perform job duties.
The only company that I can think of forced dogfooding of the "provider" side being worse at (besides obvious jokes like MindGeek) is Airbnb.
But that's not all: it doesn't accurately simulate the contractor experience at all! There's no pressure! They have no incentive to actually ride fast (and, from my experience from encountering delivery riders as an NYC cyclist, in the wrong direction, at night, with no lights...) since there's no actual correlation between my delivery performance and my TC. It's just SWEs cosplaying as delivery people for a day.
As someone who is now a C-suite exec, I was aghast reading that discussion. If you're a CTO who doesn't code, so be it do what works for you, CTO is such a broad title that there are plenty of companies that don't need a CTO who codes. But the shock was at how adamant people were that CTOs have better things to do than contribute to software. Not only have I worked with excellent CTOs who all contributed source code to projects, many CTOs I admire and look up to do the same, such as John Carmack, Fabrice Bellard, Cal Henderson.
There are domains where a CTO absolutely need not code, and coding is not the end all be all of building a technology company by any means, but it's hard to imagine many situations where CTOs who do code are doing it at the expense of a more valuable skill, and furthermore I can think of many companies that would benefit from having CTOs who did actually contribute source code.
There's a belief among managers that "profesionnal management" is a thing and that there's no need to understand what you are managing; only the art of management itself.
Think about Apple under John Sculley or Boeing since the merger with McDonald Douglas...
I think GP’s claimed belief “among managers” is true for a very small sliver of the management ranks (and I think a smaller sliver than in the internet commenters’ case).
I've seen this pattern many times on smaller and larger scales. Betting on a technical manager is almost always the correct bet to place.
It might help in e.g. startups, but I think it'd have less of an impact than you think it will.
So I don't think it's managers who need this so much as engineers who can do something to help, because as a colleague put it, laziness is a powerful motivator for engineers.
Managing by walking around is still amazingly more successful than managing by arbitrary metrics, but it's still rare.
Seems to me that dealing with that is even more of a problem with requiring engineers to do one particular class of the work one day a month as it is for having the engineers engage with those during the work as part of product design and development, so I’m not sure what relevance it has to the present discussion.
Engineers are usually far removed
See how things are from the bottom up.