As a former Uber engineer I did the employee delivering program a couple of times (pre-covid) and it was really eye opening. I’m based in Amsterdam so cycled on bicycle to make deliveries - it’s hard work, but also was a great way to explore the city and discovered some great eateries I wouldn’t have gone to otherwise.
I still remember a story about being yelled out of a restaurant for coming in to pick up a delivery. The restaurant owner set a message to couriers in the app that instructed us to wait outside for the pickup, but I didn’t see it because the text was so small. Instantly filed a bug report for the Driver app team to make the messages easier to read!
I was once in sales for a majors electronic components distributor. All salespeople and sales management were required to spend two weeks in the warehouse for onboarding, and were told that if the warehouse staff didn’t give them a favourable evaluation, they would fail probation and be let go.
We often debated whether this was actually effective overall, or was just a culture-building stunt (like Amazon’s door desks). But there was no question that it helped the sales team quickly build relationships with fulfillment, relationships that could make or break their ability to solve problems for their customers.
I started one job as a software dev and new starters had to spend the first two weeks with customer support, answering requests and basically just learning about what the users generally experienced.
It was onboarding so I was still setting up my environment at the same time, but I credit that startup for shifting me to a much more empathic mindset where I would learn how to question designs based on my own understanding of what it would be like for someone to have to interact with it. It also resulted in me getting on especially well with the support team.
Honestly I wish more places would do onboarding that way. Put new hires on the front-line as it were, so they understand the product from the perspective of users and those who have to run support. Maybe give people refreshers every year or so, so they don't become detached from the reality of using the product.
I was an international sales for an electronics company. One time there was customer payment delay for which held the goods at the pending-payment zone in the factory for more than 1 month!. We were basically waiting for the payment to clear before we ship. There were two 20-ft containers worth of electronics in the corner of the outgoing area. It was such an eyesore that manufacturing head yelled at sales head during every management meeting for that month.
When the customer finally cleared the payment, CEO made the responsible sales team fill the container by hand (I was one of them). But it was an eye-opening experience. We dragged our ass from our A/C equipped office and wore our usual suits and leather shoes, oh boy were we stupid. What I remember the most was how stuffy and hot the air was nearing the innermost end of the container especially when carrying boxes. The entire team was drenched afterward except somehow the ladies managed to wiggle their way out by "hey we are just gonna get everyone an ice coffee, be right back". It was fun still.
One of my favorite experiences working at a large bank was sitting in on calls in the call center for a morning. It blew my mind.
Our systems were terribly unhelpful in handling the average call. I was embarrassed to note the vast difference between the systems we gave our call center versus what we gave our customers. Also their needs were pretty much the same (obvious in retrospect). The customer-facing system had continuously been measured and improved for user experience and delight. The systems our call center used looked like a wasteland of retro tech. Agents were hopping between systems and copy-pasting sensitive customer data. For one simple customer query I saw an agent hop between 4 systems and 5 pages.
I left with my tail between my legs and a wealth of insights that continue to have an impact several years later.
Were you able to make any changes to the call center system? I feel like most banks wouldn't even be able to receive feedback like that - "you haven't been assigned the job code necessary to determine project priority, plus you have tasks in your queue already".
I imagine that customers were calling for things like needing to update their info but the website wouldn't let them, and the call center tech had to manually enter their address into 3 web forms, is that about what it was?
Great idea. Not sure why boards of directors don't require this of all their CxOs. For example, make a CEO in the travel industry sit at a counter and rent out cars or hotel rooms for a day and see if they don't demand improvements.
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.
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.
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...
I think that's a really great idea. In Germany we have a fairly strong 'grey collar' culture and this was one of the things I missed most in the UK. (and I think the US is similar in that regard).
The huge division between 'service workers' and professionals I think is not good for companies but much more importantly it's bad socially. People lose empathy for the day-to-day problems of what is probably the majority of employees in numbers and it creates a class of people living in a bubble. You learn a lot of humility pretty quickly if you go from management work or coding to carrying packages around and having to deal with angry customers.
I wonder what changes you'd see at companies like Facebook if the management had to sit in one of their outsourced content moderation centers for a few weeks.
I used to drive Uber and deliver Uber Eats for something to do in retirement. I don't know why, but it struck me funny that I delivered a bunch of smoothies to the Uber Palo Alto office. They tipped well.
Many years ago I had a ride in the Bay Area with an Uber investor as the driver (he was a partner at one of the VCs). It was quite an interesting ride has he wanted to know a lot about why I choose to use Uber and all the good and bad about it. He told me that while they are already investing, he wanted to better understand how Uber is coming along.
I can relate to this very well, and it was very intriguing situation to be in. I used to work part time delivering groceries with Instacart and I actually delivered stationery stuff to Instacart Office in Downtown Toronto. Bonus: I got to pick-up a cool sticker while on my way out.
I understand why this would be valuable from a team-building perspective (and support it as such), but I'm not totally convinced this is valuable as a way to improve the product.
Typical user testing is monitoring your users as they succeed/fail to use your product. So I could imagine developers monitoring a sampling of Doordash drivers (with a dashcam or the like) as they use their apps in a typical delivery process.
White-collar Doordash engineers/CxOs doing a blue-collar tour for a day would provide insight into some of the initial onboarding struggles for the "new driver" persona, but seems like it would provide limited feedback for the "experienced driver" persona. Even then, app devs/designers are so familiar with getting around odd workflows in their apps that they wouldn't really represent a new driver. It risks biasing product development in a particular way.
> "It risks biasing product development in a particular way."
I'd agree that it's biased, but I still think it's valuable. Being intimately familiar with all possible personas would be nice, however I'd hope that Engineers/PMs/Employees will use this as an additional input into their decisions about how to run the business. Just as they already use a combination of metrics, customer interviews, financial impact, and intuition about the future when deciding how to operate.
Perhaps it'd be valuable for employees to do "ride-alongs" with experienced dashers for the additional perspective you mention
They're not doing it for a day, they are doing it once a month. Eventually they will get out of the newbie persona and into the casual one, which is the vast majority of drivers for these kinds of apps AFAIK.
Eating your own dogfood is powerful at many companies, and a bad sign at a B2C company if your staff don't use it unless there are special circumstances that prevent them.
Personas are just that, models. Models are wrong but useful.
There is a ton of unspoken information that even veteran users don't communicate. I used to sit for hours watching people use microscopes, and learned way more in those hours than I would have sitting at my compiler. Many of my really killer ideas came from watching users.
Will DoorDash be paying for the employees to rent a car to make deliveries? No way I’m risking my new car on delivering groceries. No way I’m paying for commercial auto insurance either (I suspect my normal policy won’t cover DoorDash or other gig activities).
Yeah I am very confused on this. Is the idea to develop customer empathy or deliverer empathy? Wouldnt I get customer empathy by you know actually being a customer? What if I am not a customer? Does that mean I cannot get a job here? If this is the right thing to do how should this extend to other companies? Say CIA? Grindr/Tinder? On a more general note what suggests I cannot have customer empathy or give my best just because I don't prefer doing this?
Gemba walks denote the action of going to see the actual process, understand the work, ask questions, and learn. It is also known as one fundamental part of Lean management philosophy.
> "As the company grew, the founders wanted everyone to experience different parts of the product so we could get closer to all our audiences and understand how the product works," a DoorDash spokesperson said
I like this idea. I wish insurance company management and software engineers would handle some insurance claims. The processes they create without experience are poop.
I kind of wish those writing cloud services were forced to use and build things on those services. I suspect it would result in a good number of usability issues - like consistency in networking in different services.
Some engineers will complain they didn’t sign up for this, but those ones aren’t truly committed to figuring how to make things better for the deliverers, and you could argue it’s a wash to watch them go elsewhere.
As long as they let them (engineers who work at door dash) do two things I would love this myself (as an engineer, who doesn’t have to do labor or gig jobs)
1) - let them keep the same money DoorDash drivers would get
2) - give them as much credits in door dash food as the customers they’ve served ordered.
(Maybe 3) - provide a cheap reliable fuel efficient vehicle
This both proves it isn’t about skimping costs by making engineers deliver cuz they would lose more this way, but they probably would get super motivated engineers (those that stay), who would be motivated to figure out how to get more customers.
I think this is pretty cool. I wanted to do something like this at work. I work on a platform internal infra team and was thinking we should use our own service in some of our team tools we build. People seemed somewhat onboard with the idea but using it seemed like it was becoming pretty over-engineered for our own small uses.
sounds like an interesting way to break up the monotony of work too and actually see the effect of changes you make. It kills my motivation sometimes when something gets rolled out and you don't really see an impact
I sat with customer service for years as an application support engineer. I was able to learn the business much faster than if I was just talking to other devs and IT people who had barely groped one part of the elephant.
Normally, if you ask to be integrated with the business people look at you like you just crawled out of a swamp. Personally, I have a hard time deciphering code if I don't know the business case (intent) first...once I have that knowledge the code is easy to read. Rarely is code expressed in domain language.
Stupid question: I assume that some of those employees -- if only some of the software/UI devs -- must be disabled or mobility-challenged.
How are they going to square this policy with disabilities legislation when it runs into a wheelchair user or someone with juvenile onset rheumatoid arthritis?
Or are they unintentionally indicating that as an employer they discriminate against the disabled?
(Wanting all your employees to be familiar with what the job demands is in principle a good idea, but the second-order consequences can be a bear.)
Someone who can't drive could simply join another employee who can, basically a ride along, maybe not as useful but still doable. If you can't do that there are other customer service jobs you could do like a call center or something.
I don’t know if they still do it, but Home Depot used to have the same policy when you went to work at the headquarters in Atlanta. No matter your role, you had to go work at a Home Depot store for a week. You got to choose which store though, didn’t have to be the ones in Atlanta.
Going to guess that was only for direct employees. I was a contractor at the SSC in various software development roles and it was never suggested that I go work at a store though it wouldn't surprise me if it was policy for actual employees. I did hear a lot about the importance of "voluntarily" contributing to the "Orange Voice" which is Home Depot's lobbying organization. Haven't seen any other company push so hard for workers to pay into the company's lobbying arm.
Absolutely, if you take pride in what you work on, you should definitely step in the shoes of the core users of your app - the lone gig worker. I used to deliver with UberEats, occasionally I would go to a restaurant that would refuse to let me use washrooms until I buy something on the menu. I didn't fuss about it because I'd go to next restaurant that would let me in. But I have seen drivers arguing and just walking out of the restaurant if they were refused access to a washroom. I raised this with UberEats casually and the customer support rep told me they can't do anything, it's the choice of the restaurant.
But when COVID started, the situation worsened, majority of the restaurants including big national chains stopped delivery people from using the washrooms (at least in Toronto, Ontario). I happened to deliver around that time and I delivered for about a week and then I realized I couldn't hold my pee for longer times, and didn't want to use bottles to pee. This was a real problem and I can't believe it took Ontario more than a full year to pass the legislation in that regard [1].
What's even more sadder is this happened on upscale so-called Vegan restaurants, owners advertising fair food policies and organic products and customers ordering as per their convenience thinking they are doing great good by ordering from these places. None of the parties customer, owner or the platform knew that the food was being delivered at the price of human dignity under a very simple matter of common decency. A basic need to have access to a washroom was being denied. It is certainly the most ironical experience of my life.
TL;DR : There are actual problems that needs to be discovered and solved because each party thriving in the gig economy thinks 'its not our problem'. This can happen a lot faster if some of the staff of these companies actually goes through the experience end to end.
The "it wasn't part of the job description" engineer would be on my short list for reevaluation. In a dynamic org, change is constant, and stick-in-the-mud complainers like this range from underproductive to actively toxic. If it's just an isolated bad day, fine, but if it's an underlying 'not-my'job' attitude, then they're likely better employed elsewhere.
This practice should be pretty standard, as well as flexible roles & responsibilities, mentoring/interning, etc. to spread & grow knowledge as much as possible.
Sounds like a great way to end up even more short handed in a tight labor market, especially when there are plenty of other employers who aren't going to make similar demands. "My way or the highway" isn't a great policy when you need them much more than they need you.
[+] [-] nudgeee|4 years ago|reply
I still remember a story about being yelled out of a restaurant for coming in to pick up a delivery. The restaurant owner set a message to couriers in the app that instructed us to wait outside for the pickup, but I didn’t see it because the text was so small. Instantly filed a bug report for the Driver app team to make the messages easier to read!
[+] [-] whoisburbansky|4 years ago|reply
[+] [-] a4isms|4 years ago|reply
We often debated whether this was actually effective overall, or was just a culture-building stunt (like Amazon’s door desks). But there was no question that it helped the sales team quickly build relationships with fulfillment, relationships that could make or break their ability to solve problems for their customers.
[+] [-] ljm|4 years ago|reply
It was onboarding so I was still setting up my environment at the same time, but I credit that startup for shifting me to a much more empathic mindset where I would learn how to question designs based on my own understanding of what it would be like for someone to have to interact with it. It also resulted in me getting on especially well with the support team.
Honestly I wish more places would do onboarding that way. Put new hires on the front-line as it were, so they understand the product from the perspective of users and those who have to run support. Maybe give people refreshers every year or so, so they don't become detached from the reality of using the product.
[+] [-] davidjytang|4 years ago|reply
When the customer finally cleared the payment, CEO made the responsible sales team fill the container by hand (I was one of them). But it was an eye-opening experience. We dragged our ass from our A/C equipped office and wore our usual suits and leather shoes, oh boy were we stupid. What I remember the most was how stuffy and hot the air was nearing the innermost end of the container especially when carrying boxes. The entire team was drenched afterward except somehow the ladies managed to wiggle their way out by "hey we are just gonna get everyone an ice coffee, be right back". It was fun still.
[+] [-] ridiculousthrow|4 years ago|reply
[+] [-] CaptainJustin|4 years ago|reply
Our systems were terribly unhelpful in handling the average call. I was embarrassed to note the vast difference between the systems we gave our call center versus what we gave our customers. Also their needs were pretty much the same (obvious in retrospect). The customer-facing system had continuously been measured and improved for user experience and delight. The systems our call center used looked like a wasteland of retro tech. Agents were hopping between systems and copy-pasting sensitive customer data. For one simple customer query I saw an agent hop between 4 systems and 5 pages.
I left with my tail between my legs and a wealth of insights that continue to have an impact several years later.
[+] [-] PascLeRasc|4 years ago|reply
I imagine that customers were calling for things like needing to update their info but the website wouldn't let them, and the call center tech had to manually enter their address into 3 web forms, is that about what it was?
[+] [-] notreallyserio|4 years ago|reply
[+] [-] snoog|4 years ago|reply
- 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.
[+] [-] Kranar|4 years ago|reply
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.
[+] [-] sokoloff|4 years ago|reply
[+] [-] 908B64B197|4 years ago|reply
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...
[+] [-] rovr138|4 years ago|reply
[+] [-] Barrin92|4 years ago|reply
The huge division between 'service workers' and professionals I think is not good for companies but much more importantly it's bad socially. People lose empathy for the day-to-day problems of what is probably the majority of employees in numbers and it creates a class of people living in a bubble. You learn a lot of humility pretty quickly if you go from management work or coding to carrying packages around and having to deal with angry customers.
I wonder what changes you'd see at companies like Facebook if the management had to sit in one of their outsourced content moderation centers for a few weeks.
[+] [-] mwattsun|4 years ago|reply
[+] [-] Schweigi|4 years ago|reply
[+] [-] worker_thread|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] carabiner|4 years ago|reply
[+] [-] ferdowsi|4 years ago|reply
Typical user testing is monitoring your users as they succeed/fail to use your product. So I could imagine developers monitoring a sampling of Doordash drivers (with a dashcam or the like) as they use their apps in a typical delivery process.
White-collar Doordash engineers/CxOs doing a blue-collar tour for a day would provide insight into some of the initial onboarding struggles for the "new driver" persona, but seems like it would provide limited feedback for the "experienced driver" persona. Even then, app devs/designers are so familiar with getting around odd workflows in their apps that they wouldn't really represent a new driver. It risks biasing product development in a particular way.
[+] [-] ford|4 years ago|reply
I'd agree that it's biased, but I still think it's valuable. Being intimately familiar with all possible personas would be nice, however I'd hope that Engineers/PMs/Employees will use this as an additional input into their decisions about how to run the business. Just as they already use a combination of metrics, customer interviews, financial impact, and intuition about the future when deciding how to operate.
Perhaps it'd be valuable for employees to do "ride-alongs" with experienced dashers for the additional perspective you mention
[+] [-] novok|4 years ago|reply
Eating your own dogfood is powerful at many companies, and a bad sign at a B2C company if your staff don't use it unless there are special circumstances that prevent them.
[+] [-] anarticle|4 years ago|reply
There is a ton of unspoken information that even veteran users don't communicate. I used to sit for hours watching people use microscopes, and learned way more in those hours than I would have sitting at my compiler. Many of my really killer ideas came from watching users.
It's hard to know what you don't know.
https://en.wikipedia.org/wiki/The_Design_of_Everyday_Things
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] hoppyhoppy2|4 years ago|reply
[+] [-] alistairSH|4 years ago|reply
[+] [-] flashgordon|4 years ago|reply
[+] [-] pylua|4 years ago|reply
[+] [-] masterof0|4 years ago|reply
[+] [-] riffic|4 years ago|reply
Gemba walks denote the action of going to see the actual process, understand the work, ask questions, and learn. It is also known as one fundamental part of Lean management philosophy.
[+] [-] itamarst|4 years ago|reply
[+] [-] awb|4 years ago|reply
> "As the company grew, the founders wanted everyone to experience different parts of the product so we could get closer to all our audiences and understand how the product works," a DoorDash spokesperson said
[+] [-] oxymoran|4 years ago|reply
[+] [-] jmspring|4 years ago|reply
[+] [-] mostertoaster|4 years ago|reply
Some engineers will complain they didn’t sign up for this, but those ones aren’t truly committed to figuring how to make things better for the deliverers, and you could argue it’s a wash to watch them go elsewhere.
As long as they let them (engineers who work at door dash) do two things I would love this myself (as an engineer, who doesn’t have to do labor or gig jobs)
1) - let them keep the same money DoorDash drivers would get 2) - give them as much credits in door dash food as the customers they’ve served ordered. (Maybe 3) - provide a cheap reliable fuel efficient vehicle
This both proves it isn’t about skimping costs by making engineers deliver cuz they would lose more this way, but they probably would get super motivated engineers (those that stay), who would be motivated to figure out how to get more customers.
[+] [-] tayo42|4 years ago|reply
sounds like an interesting way to break up the monotony of work too and actually see the effect of changes you make. It kills my motivation sometimes when something gets rolled out and you don't really see an impact
[+] [-] datavirtue|4 years ago|reply
Normally, if you ask to be integrated with the business people look at you like you just crawled out of a swamp. Personally, I have a hard time deciphering code if I don't know the business case (intent) first...once I have that knowledge the code is easy to read. Rarely is code expressed in domain language.
[+] [-] cstross|4 years ago|reply
How are they going to square this policy with disabilities legislation when it runs into a wheelchair user or someone with juvenile onset rheumatoid arthritis?
Or are they unintentionally indicating that as an employer they discriminate against the disabled?
(Wanting all your employees to be familiar with what the job demands is in principle a good idea, but the second-order consequences can be a bear.)
[+] [-] tonymet|4 years ago|reply
[+] [-] s0rce|4 years ago|reply
[+] [-] atl_punk|4 years ago|reply
[+] [-] Mountain_Skies|4 years ago|reply
[+] [-] worker_thread|4 years ago|reply
But when COVID started, the situation worsened, majority of the restaurants including big national chains stopped delivery people from using the washrooms (at least in Toronto, Ontario). I happened to deliver around that time and I delivered for about a week and then I realized I couldn't hold my pee for longer times, and didn't want to use bottles to pee. This was a real problem and I can't believe it took Ontario more than a full year to pass the legislation in that regard [1].
What's even more sadder is this happened on upscale so-called Vegan restaurants, owners advertising fair food policies and organic products and customers ordering as per their convenience thinking they are doing great good by ordering from these places. None of the parties customer, owner or the platform knew that the food was being delivered at the price of human dignity under a very simple matter of common decency. A basic need to have access to a washroom was being denied. It is certainly the most ironical experience of my life.
TL;DR : There are actual problems that needs to be discovered and solved because each party thriving in the gig economy thinks 'its not our problem'. This can happen a lot faster if some of the staff of these companies actually goes through the experience end to end.
1. https://toronto.ctvnews.ca/ontario-set-to-introduce-legislat....
[+] [-] toss1|4 years ago|reply
The "it wasn't part of the job description" engineer would be on my short list for reevaluation. In a dynamic org, change is constant, and stick-in-the-mud complainers like this range from underproductive to actively toxic. If it's just an isolated bad day, fine, but if it's an underlying 'not-my'job' attitude, then they're likely better employed elsewhere.
This practice should be pretty standard, as well as flexible roles & responsibilities, mentoring/interning, etc. to spread & grow knowledge as much as possible.
[+] [-] swongel|4 years ago|reply
Talk about toxic, this kind of garbage is why workers need strong labor laws and unions protecting them.
[+] [-] Mountain_Skies|4 years ago|reply