Dogfooding is a good idea in general, but it seems like a horrible idea for Doordash specifically:

- 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.

Perhaps Doordash should treat their employees as employees, providing the appropriate insurances and training to perform their work safely.

Forget delivering food, just a week ago there was a discussion on here where the predominant attitude in the comments was about how CTOs shouldn't be programming, and CTOs who program are wasting their time when they could be doing much more valuable things like the "setting direction" and "vision" of the company.

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.

One of my friends is a CTO. In some ways he was my first boss too (it depends what counts as a real job). He actually moved from programming to management, because for him writing code wasn't something he was passionate about and he felt his skills were more appropriate in managing tech (I'm sure the money helps too). But though I haven't worked for his present outfit, I'm sure I'd find that where it seemed appropriate he's still writing toy SML or Python code that shows what he wants, knowing the finished system will likely be written in another language entirely. Not doing that seems as crazy as if you had an exec with good German, addressing your German-speaking team, via a translator just because that's how their predecessors who didn't speak German did it. He can write code and that's the natural way to express how the code should work.

Fabrice Bellard is a CTO? Are you talking about this guy?: https://bellard.org

Yep that's the one, and yes he is a CTO.

Worked at a place where a natural disaster knocked our call center offline for a couple of weeks. We relocated the center to our HQ and marketing and tech staffed the calls. I made several improvements to our call center tools after just a couple of shifts taking calls. None were difficult, but it would have taken quite a while for those requests to come in naturally I think.

> Not sure why boards of directors don't require this of all their CxOs.

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...

This is certainly true among some managers, and is also how you wind up with useless project managers and "scrum masters" who can't actually do anything except send an email or slack.

Is this based on something or just your perspective?

Observations really.

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.

Being an internet commenter doesn’t require any particular expertise in the thing…

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).

It certainly seems true of a breed of MBA. When interviewing candidates for PM it's interesting to see the breakdown in people who care about how the product works and those who consider it a widget to be put in a box. "Bring the customer demands to the eng team (without providing a useful translation)".

I don't think just a day, but yes. Make them work there with some frequency and they will start hating it enough to demand improvements.

Make them eat their own dog food at least once quarterly, under a pseudonym, with no special treatment. That'd change a whole lot of companies.

I don't think it would. I'd like to believe leadership in companies that exploit their workers know exactly what they're doing, grilling burgers for a day won't change that.

It might help in e.g. startups, but I think it'd have less of an impact than you think it will.

I entered software engineering by making simple web tools for my job in customer support. For a while I continued making tools for the department and those were some of my most effective projects because I knew the domain intimately and what the pain points were and the mentality of my former colleagues so I knew what kind of UX would work for my users.

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.

If engineers aren't working closely with the end-users who do each piece of work their systems directly support most frequently on a regular basis in the course of development, doing deliveries once (whether that's one delivery or one shift) a month won't make up for that fundamental process defect, and if they are, then it won't add anything meaningful for what that process already provides.

These days it's a lucky accident when the engineers and the end users are on the same continent and maybe speak the same language. The business will certainly optimize for lowest cost until it becomes so bad that it's impossible to overlook.

Managing by walking around is still amazingly more successful than managing by arbitrary metrics, but it's still rare.

> These days it's a lucky accident when the engineers and the end users are on the same continent and maybe speak the same language

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.

That sounds like every company everywhere.

Engineers are usually far removed

Its not just exploitation, the way managers imagine the work is done is very different from how it really gets done. Imagining how things work is never exactly how it works and you cant imagine how far off you could be. We've all been surprised by reality.

There's some amount of overlap between what workers perceive as painful or abusive practices or systems and things that are flat out wasteful or pointless. Sometimes the pointlessness is what pisses people off.

Make them go 3 days a week every X time. Sometimes as a new employee and sometimes as a transfer.

See how things are from the bottom up.

And fire them if they don't perform!

I bet a lot of them will get called out on things.. Speed, policies vs how we actually do it, etc.

There is a show called "Undercover Boss" that does this.