I recall Amazon used to do something similar. Executives would sometimes take customer service shifts. The goal isn't PR or worker morale - most people see through stunts like that. The real goal is to help leaders better understand their product, its problems, and customer frustrations.
> Executives would sometimes take customer service shifts.
This won't happen among most companies, but I'd love to see that become a common practice with at least some high-level developers.
There's so many pain points in many customer service organizations that are easily solvable if a developer understood the frustration and waste with many customer service tasks. Nothing motivates more than having to do some annoying manual billing process that's error prone or looking up customer information by logging into 5 different systems.
Alas, Google has no customer service, so their developers shall be placed in the void until morale improves.
This should absolutely be a thing for vertical integration developers. If you're developing cashier software for Target, you should have to use it under realistic circumstances sometimes. Same for Amazon driving software, helpdesk software, sales, etc.
When I worked for a large logistics company we’d have a few days a year where we’d go downstairs and shadow someone using our software. It was very informative. The UX people were redesigning workflow to be “easier” and less information dense and the experienced people (who worked mostly on commissions mind you) where very pissed and wanted their hot keys and their at a glance information.
> The UX people were redesigning workflow to be “easier” and less information dense
I never really understood why they focus on these two things. They're good for rank beginners, I suppose, but once you've even approached competency, those "easier" workflows inevitably end up being a huge pain in the ass, and lower information density is actively a terrible thing.
> They're good for rank beginners, I suppose, but once you've even approached competency,
It's because you're aiming for a system where you don't need to reward the competency of long term employees and can instead just pluck random people off the street, pay them next to nothing and replace them when they quit.
> The UX people were redesigning workflow to be “easier” and less information dense and the experienced people (who worked mostly on commissions mind you) where very pissed and wanted their hot keys and their at a glance information.
It was very eye opening.
Just curious. Many applications have some kind of "Settings" or "Preferences" section with some kind of App UI customization being possible. Often it's just a set of fairly simple features like picking a favorite background color for your App or being able to upload your own avatar or something.
But are there Apps out there where you can pick between say "Beginner and Expert" modes and have a radically different UI and UX depending on how experienced and comfortable you are? (Gmail sort of has a touch of that concept with the ability to either have a dense or comfortable email layout, but that's barely scratching the surface of what's possible)
PS: I realize that trying to develop, maintain, and support mobile and desktop versions of different versions of the same App would morph into a significant and unpleasant challenge, but being able to pick the type of UI might be a possible solution that pleases more types of users.
> But are there Apps out there where you can pick between say "Beginner and Expert" modes
Yes, plenty. They've never been particularly popular, because they tend to impose an "all or nothing" switch to the user: by going Expert, you're suddenly overwhelmed by loads of options you don't know and don't understand. People mostly prefer a gentler path, where you become familiar with one feature at a time when you need it particularly badly.
This, in theory, would suggest that the best approach is to morph the interface over time, making those advanced-but-useful features easier to access once discovered. But most people also hate interfaces that change, so in practice that approach doesn't work well. Maybe it will all be solved by a ML engine that looks at what you do every day and automatically serves you the features it thinks you'll want; but Microsoft kinda tried that in a bunch of places and I don't think it was particularly successful.
1) Just thinking out loud here, but some games have the most complex and information dense user interfaces you'll ever see. And sometimes they solve this problem by introducing new features in sort of a well-designed, first-class tutorial over the course of a few missions in a single-player campaign. Maybe Apps can try the same approach?
2) I can't help but think that many UI problems would be solved by Apps replacing meaningless icons with actual text labels. I can't remember what half the random symbols on software I use daily for hours means. If something is a sharing icon or a saving icon, I have no clue half the time. But simply having text labels on buttons and links everywhere would make all software a lot more explorable and understandable.
> some games have the most complex and information dense user interfaces
Completely different audiences and incentives. Gamers game because they want to; most people use apps because they have to, to get shit done and pay the rent. Gamers are motivated to inspect capabilities in order to get an advantage, to solve the gameplay puzzle, even just to kill time; people are motivated to get the hell out of apps as quickly as possible and go shopping.
I don't care about the capabilities of MS Word, I just want to type some stuff out. I don't care that Outlook can read RSS feeds, I just want to send an email. I skip every single onboarding wizard I can skip, because I honestly don't give a shit about 90% of "features" out there. If people cared about advanced features, we'd all be using Emacs.
> many UI problems would be solved by Apps replacing meaningless icons with actual text labels
I don't disagree in principle, but the reality is that text takes a lot of screen real estate, scales badly, and most people think text-heavy UIs just look ugly. We could definitely have better and more meaningful icons though; the "material" anti-skeuomorphing bullshit has inflicted a lot of damage on the credibility of UX practitioners, over the last decade. The 90s in comparison were a dream.
I don't think we really disagree on much, just having a conversation with some random points to feel out what I think about this.
1) I understand that the motivation for playing games is far different from the motivation for work. My main point is just to indicate that there's some games that basically simulate entire economies (on a planetary or even galaxy-wide scale) and a large amount of intricate detail. Using some approaches from games to display UI might help in the business world too. (and might have other benefits)
2) Text taking up more real estate than an icon can in a sense sometimes be considered a big feature rather than a bug. A big part of good UI design is picking and choosing what UI items belong on a particular screen. Icons IMO can lend themselves to bad overall practices because you can fit more junk into every single screen. If you need to fit every single possible command into one screen, the command line is the best method for that.
>The UX people were redesigning workflow to be “easier” and less information dense and the experienced people (who worked mostly on commissions mind you) where very pissed and wanted their hot keys and their at a glance information.
That doesn't necessarily mean that the UX people were wrong though. Even if their changes made the experienced people slightly slower, it could be worth it if it significantly sped up onboarding.
The math isn't straightforward. With a high enough rate of churn, there can be more onboarding work hours than post-onboarding work hours, especially if the onboarding ramp up time takes a while (as it presumably would if you only optimized for experienced use). And high rates of churn are not exactly uncommon.
Also, everybody goes through onboarding, and initial impressions have a lot of power. It's pretty easy to create a system that everyone hates just because it's a little difficult during onboarding. Social reinforcement can be stronger than reality.
(Personally, I still lean towards optimizing for experienced use, if you can do it without sacrificing the onboarding experience too much. Hotkeys that the new employee never needs to see or know about are a typical example, though I prefer a smoother ramp by mentioning the key on applicable menu items. The newbie can ignore it, the intermediate user can learn from it, the experienced user can ignore the menu.)
I suppose that the Devil's Advocate sort of counterargument is that for many startups or businesses on the bubble of survival, their most important task is for paying customers to understand the basics of their software and get hooked with a paid subscription quickly. From that perspective, it's ok if customers don't absolutely LOVE the software in a year or two, as long as they like it just enough to be paying today.
> Why optimize for the one-time thing at the expense of the everyday use?
I'm not necessarily endorsing this perspective, and it depends on the specifics, but there are cases where this makes business sense. If you take a task that requires an expensive expert and make it something that an unskilled worker can do then you you can lower overall labor costs even if each user is less efficient in the new system.
It's a bit more complicated than that. Here's a great article that explains how users can be sorted into categories (from beginner to student to expert) and what each of them wants and needs.
It is possible to achieve both. Making an explicit choice to degrade the ability and satisfaction of experienced employees is just optimizing for staff churn.
This is a constant fight. The UI design people want a bunch of pretty white space, and the actual users want dense information. Despite people insisting they're "data driven", the design people rarely seem to appreciate the feedback.
> There's so many pain points in many customer service organizations that are easily solvable if a developer understood
AND if a developer actually has the opportunity to do something about it. Many companies overbook their developers time such that deadlines are constantly missed, where in that prioritization is their room for significant improvements to other services?
If the Engineering Manager is judged by their project throughput how does the EM feel about their reports working outside of that scope?
If there's value in Customer Service there should be a distinct team working on it and it shouldn't become a second job existing employees have to work.
100% agree, especially if it is industry specific specialty software. Seen so many applications that have processes that only make sense to the people that developed it and are at best tolerated by the users that have no other choice than to use it.
This rings so true. As a designer it's invaluable to have teammates with ___domain expertise—they have a much better idea about customer pain points. Honestly, they can usually articulate the problems better than customers can in interviews.
Where I work it's not uncommon for people to come into engineering through support > support engineering > software engineering. At one point our top AE decided he didn't want the stress of selling and went from AE > PM > UI Engineer. These have always been some of my favorite engineers to work with.
> Alas, Google has no customer service, so their developers shall be placed in the void until morale improves.
We had customer support for Google Fiber, and engineers could pair with a CSR to listen to calls whenever they wanted to. We were widely regarded as having excellent customer support, and of course, customers were calling us about our highest priority but most difficult to fix bugs.
When i started at Shopify we had to setup a store and do some customer support. It was a great way to understand the product, especially since my role wasn't going to be customer facing at all.
If developers spent more time in sales or customer service...many of them would quit out of frustration, but some would refactor the world, also out of frustration.
The issue in my opinion is their day or two on the job really doesn't give them a good picture of what's going on. Sure they might see a few things but they could just as easily be an anomaly as they could be systemic. I wish upper management that are brought in from the outside would be required to work a month or two in the field and live on those wages. For example at Starbucks in the 2 days he works he might see that the espresso machine is getting loaded wrong 40% of the time slowing up the line. Seeing this he might go back to the mothership and decide everyone using the espresso machine needs more training to reduce the failures. What he is missing is that there are supposed to be three people working not two and the person making espresso is working his fifth double shift this week because the wages are so low they can't pay their rent and is making errors because he's tired. He would have also missed that the manager had sent a worker home that day and the day before because it wasn't busy and the manager wanted to improve his margins. He also missed the next day when it was really busy that same manager was demanding that an employee on their day off come in and work because they were busy and if they didn't come in they would be fired (leaving them even more short of people and creating more delays). It's like a person who fasts for 24h saying they know what it's like to be starving. If you really want to see what's going on a day or two simply won't cut it you need some time for things to sink in and if you don't know what's really going on how can you run a business properly?
Eh, I think it depends on how canny the executive running the experiment is and how much experience they have in the particular part of the industry. I worked in restaurants when I was younger and now have done a lot of sales-side and logistics management, and it wouldn't take more than a day of working in a new restaurant for me to accurately understand some of the major issues going on. You just have to be open-minded, identify the best employees, and let them freely bitch at you for about two hours while trying to do the work with them. That'll give you a good sense of the big blockers at that particular restaurant. Same is true for any software org.
The difference will be if you think that you're going to come up with better prescriptions for success than they are (and this is where the level of executive cleverness comes into play). One day per month in a Starbucks shop and then giving technical directives wouldn't make any sense, but one day per month in a Starbucks shop and then redirecting budgeting at a corporate level might.
You’re making a lot of assumptions about how dumb he will be. Like you think he will just overfit on every detail instead of asking the store manager or employees about what he experienced? You think he will not work in more than one store, in more than one geography? Cmon man.
Honestly I think you're making as many assumptions as the parent commenter--I agree you're right that the portrayal of the exec is really biased towards assuming stupidity, but it really depends on the quality of the executive and the people that hired them. It's completely possible to get a total dumbass, and also possible to get a genius.
My first career was a chef. When I asked a friend of the family who owned a restaurant when I was teenager what steps I should take to become a chef, the advice he gave was "Get a job as a dishwasher in a restaurant because the most important thing you need to know is to respect your dishwasher because anytime everything goes wrong and you are in a jam, it is your dishwasher who will save you." Unknown to me the restaurant that hired me when I was 17 as a dishwasher was also one of the most prestigious restaurants in California in the early 90s which lead to years cooking in Michelin Star restaurants. Good advice.
Reminds me of something that my father told me:
"Always be nice to nurses and janitors. Nurses run hospitals. Janitors run buildings. Secretaries run offices."
In the case of offices, the receptionist is the most important and powerful person there. They are the ones who have the ear of everybody else, have control of access to everyone else, know how things really work (as opposed to how everyone says they work), etc.
A good or bad word from the receptionist can literally make or break business deals.
A line cook can't stop what they are doing for even 5 minutes during a 4 hour period of time. There might be a lull for 15 minutes between seatings to run to the bathroom, but sometimes not. It is brutal work. Because of the thin margins in restaurants, they tend to be under staffed. When something needs to be fixed during service, maybe a plumbing problem, the ice machine broke, or a purveyor didn't deliver the correct items so someone needs to run to the supermarket, it is usually the dishwasher who fixes the problem. The pay is awful for a dishwasher. Likely, especially in California, the dishwasher in the restaurant you are eating at isn't legally allowed to be in the United States. Other times, the dishwasher will have a criminal record and can't find other work. Another dishwasher in Portland had his entire face tattooed with body modifications. They are in that position for a reason. The point is paying the dishwasher in respect if not higher wages is important to the survival of a restaurant. A chef depends on this person who is in the lowest social position to have his or her back.
If it's anything like the small, dinky restaurant i washed plates for, the reality is that the restaurant doesn't have enough plates and pans to satisfy every order on a busy night without washing something. Pans in particular are reused multiple times during a shift, and they better be well-scrubbed, because you don't want your fancy ingredients tasting of something else.
They want them to understand customer frustrations, not employee devastation. Plus, make the C-suite realize how they treat the "lowest" employees of the company and they might not want to work there anymore, have to tread carefully there.
I worked at a small (in Amazon scale - still the largest in the country) home grocery delivery service and everyone pre corona had to spend their 2 first weeks in the warehouse. Everyone had done it, including managers and c-level
The couple of people I personally know that have worked at Amazon warehouses says they're pretty well ran in comparison to other warehouses.
And I know personally that my experience working in a small-business warehouse back when I was young was absolutely garbage. Smaller businesses rarely get any news coverage, but I worked in a warehouse with zero ventilation, no safety training, no safety equipment, nobody trained in logistics, broken and improper lifting equipment, etc. This is par for the course at a workplace with zero outside scrutiny.
Amazon warehouses are at least run by professionals in logistics, have proper safety procedures, equipment, training, etc. As I understand, the 'bad' part is the volume. But at the end of the day, even a well-run warehouse job is a warehouse job. It is physical work.
Jeff Wilke (former ceo of amazon retail) used to do that during Q4 peak. It was also pretty common for engineering teams to signup to do a day in the FC so they could see what it was like.
Bezos would do one day a year operating the customer service lines.
In the UK I did some work with HMV doing Dev work on their stock systems.
Similar situation where they would send everyone in the company to work in the store, so you would actually use the system you've developed in the real world and understand why everyone always hates the software.
In this documentary about Kawasaki, they also mention that everyone has to expend some time in the production line, it seems like a great way to motivate your engineers to improve the process. https://www.youtube.com/watch?v=tg32DlveFiE
That's what I asked my boss to do for me. Pair me with someone using our tool so they can ask me to do real world tasks and see how I can handle it. Should be later this month. And will try to do one session every month or so.
The new Starbucks CEO is Laxman Narasimhan. Google says he's worth about $20m.
The previous Starbucks CEO was Howard Schultz. He's worth about $3.7b
Can somebody who is worth between $20m and $3.7b really just... hang out broad daylight behind a counter at a Starbucks from a security perspective?
Obviously I get the gap between $20m (he's just starting out, I'm sure his net worth will grow to at least $50m shortly if he does well at Starbucks) and $3.7b is huge. But at what point is going outside (without security? where people know you will be?) kind of a risk?
What exactly do you imagine is going to happen? There are lots of very rich people walking around in public all day long with little ill effects? The most you can get by robbing him is the stuff he has in his wallet, which is pretty much going to be similar to someone with a much lower net worth. If you walk around in Palo Alto, you will likely bump into a billionaire or two on a typical day.
I'm not a criminologist, but I would assume that personal safety has more to do with the environment a person occupies. Poor people are more likely to be victims of crimes than the rich. Being a recognizable celebrity or a target of organized criminals may be exceptions to the rule. How many people would recognize the Starbucks CEO on the street if they saw him?
I would believe that's the case if Narasimhan were working a full shift, but he's only working half a shift once a month. At that point why bother? What are you going to learn in 4 hours a month where all the employees are on their best behavior and the store is made immaculate prior to your arrival?
If they were paid the minimum wage too it might drive home a greater understanding of their employees as well, though unfortunately the large existing bank accounts of the CEOs ensures that any lesson that might come with that small paycheque is not likely to sink in.
And depending on the franchise owner, could also be the franchise.
My first McJob was at an owner-operated McDonalds where the owner would roll in at lunch on a Saturday in his BMW Z4, see the lunch rush, wash his hands, throw on some gloves, and call out to turn on the other side of the grill for assembly and start packing orders himself on that side to help out the workload.
Gained a lot of respect as an impressionable young adult on what a good leader looks like at that job because his efforts trickled down to his store manager and the managers underneath them.
I don't know if it's still the case but you used to have to go to Hamburger U before you could own a McD's so you knew how to do the job. I actually see it all the time and you can always tell who the owner is, instead of some really uninterested 17 year old you get a middle aged man in a pressed (insert fast food name) polo who is super happy to take your order.
Our Owner/operator was a former bicycle salesman who knew hot fries, and that was it. I wouldn't say he was hands off (he insisted that I violate civil rights/labor laws may he rot in hell), but he really didn't understand much more than squeezing out every penny.
The worst thing was that Ray Kroc's wife live in the next town over and routinely came through our drive thru. Once the lot was being re-surfaced and she was royally pissed that the drive thru was closed and she had to come inside and mingle with the hoi polloi.
Apparently this is why some of the McDonalds restaurants in the Oak Brook / Chicago area are very good (or at least perfectly to spec)... they are owned by corporate and used for executive training.
I know of several restaurant chains who do this - it's seen as very important for restaurant head office workers to understand exactly how the restaurants work and the problems that they experience.
The main reason you do this is to weed out executives who are mostly interested in the prestige. People like that are much more likely to be good at shifting the blame for problems than actually fixing or preventing problems.
