Episode 3 of this season of Architecture Corner is out (I made a guest appearance in episode 1, “Good at Innovation”). In this installment, Chris the CEO is having trouble with a new sin.
What happens when the CEO envies the social media presence of his competitors and decides to buy some followers?
Just when I thought I was done posting for the week, they suck me back in.
Juicero started lighting up my Twitter feed a little while ago. For those, like me, who have no earthly idea what Juicero is, it’s a startup that makes an “Internet-connected kitchen appliance”:
Juicero’s flagship product is a $699 countertop device that cold presses juice out of “packs” of already prepped fruit and veggies. The packs — reminiscent of the cups and pouches used in single-cup coffee brewers from Keurig, Flavia or Nespresso — cost $4 to $10 each and are available through a Juicero subscription, but not in groceries.
Juicero just picked up $70 million in Series B funding. ‘Cause digital.
There is just one hitch – you don’t actually need the high-dollar hardware to make the juice:
But after the product hit the market, some investors were surprised to discover a much cheaper alternative: You can squeeze the Juicero bags with your bare hands. Two backers said the final device was bulkier than what was originally pitched and that they were puzzled to find that customers could achieve similar results without it. Bloomberg performed its own press test, pitting a Juicero machine against a reporter’s grip. The experiment found that squeezing the bag yields nearly the same amount of juice just as quickly—and in some cases, faster—than using the device.
Fortunately (ahem), Juicero only sells the bags, at anywhere from $5 to $8 apiece, to owners of the hardware. Performance between the device and non-standard hardware (your bare hands) is mixed:
In Bloomberg’s squeeze tests, hands did the job quicker, but the device was slightly more thorough. Reporters were able to wring 7.5 ounces of juice in a minute and a half. The machine yielded 8 ounces in about two minutes.
Almost 5 years ago, I wrote a post titled “The Most Important Question”. In it I stated the following:
The most important question in architecture is “why”. When questioned about any aspect of the design, if you cannot justify the decision, you should revisit it. Being able to list outcomes, both good and bad, and explain the reasoning behind your choices will garner trust from both customers and colleagues. Most importantly, it should boost your own confidence in the design.
With a little editing:
The most important question in
architectureinnovation is “why”. When questioned about any aspect of thedesignproduct, if you cannot justify the decision, you should revisit it. Being able to list outcomes, both good and bad, and explain the reasoning behind your choices will garner trust from both customers and colleagues. Most importantly, it should boost your own confidence in thedesignproduct.
Asking “why” could have probably saved some people a lot of money, just sayin’.
Twenty-plus years in IT have led me to believe that there are very few absolutes when it comes to software systems. Two that do seem to hold true are these:
There are a variety of reasons for this situation, many of which are baked into the architecture of the enterprise. Regardless of the why, however, the two facts remain. Without a response to those issues, entropy is inevitable.
Over the past few days, I’ve seen several blog posts by two different authors dealing with this situation in two different ways:
Jason complains about the non-technical “leadership class” in his first post:
And hence we get someone making the big decisions about healthcare who knows nothing about medicine or about running hospitals or ambulance services. And we get someone in charge of all the schools who knows nothing about teaching or running a school. And we get someone in charge of a major software company whose last job was being in charge of a soft drinks company. And so on.
Again, this is fine, if they leave the technical decisions to the technical experts. And that’s where it all falls down, of course. They don’t.
The guy in charge of the NHS insists on telling doctors and nurses how they should do their jobs. The woman in charge of UK schools insists on overriding the expertise of teachers. The guy in charge of a major software company refuses to listen to the engineers about the need for automated testing. And so on.
This is the Dunning-Kruger effect writ large. CEOs and government ministers are brimming with the overconfidence of someone who doesn’t know that they don’t know.
In his second post he follows up with how to respond:
My pithy – but entirely serious – advice in that situation is Do It AnywayTM.
There are, of course, obligations implied when we Do It AnywayTM. What we’re doing must be in the best interests of stakeholders. Do It AnywayTM is not a Get Out Jail Free card for any decision you might want to justify. We are making informed decisions on their behalf. And then doing what needs to be done. Y’know. Like professionals.
I disagree. Strenuously.
If you go to the doctor and they tells you that you will need surgery at some point for some condition, would you expect to be forcibly admitted and operated on immediately?
If you were charged with a crime, would you expect your attorney to accept a plea bargain on your behalf without consultation or prior permission?
If neither of those professionals would usurp the right of their client/patient to make their own informed decision, why should we? Both of those examples would be considered malpractice and the first would be criminal assault in addition. Therefore, I disagree that acting on someone’s behalf without their knowledge or consent is a viable option.
John’s approach, rejecting helplessness and confronting the issues by communicating the costs (with justifications/evidence) is, in my opinion, the truly professional approach. We have a responsibility to make the problem visible and continue making it visible. We also have a responsibility to operate within the limits we’re given. We know far more about our area than someone higher up the management chain, but, that does not equate to knowing more in general than those higher up the management chain. Ignorance is relative. Micro-managing, getting deeper in the weeds than you need to is ineffective. If, however, you’re in the weeds, do you have the information necessary to say that the issue being “interfered with” is one without higher-level consequences? Dunning-Kruger can cut a wide swathe. Trust needs to cut both ways.
Imagine riding as a passenger in a car. You see the car drifting closer and closer to the shoulder. Do you point it out to the driver or do you just grab the wheel? You might prevent an accident or you just might cause one by steering into a vehicle coming up from behind that you didn’t see from your vantage point.
[Plymouth Savoy photo by Christopher Ziemnowicz via Wikimedia Commons]
Well, this turned out to be very much a different post than what I’d first thought.
Last Thursday, CIO published an article titled “Your Pebble smartwatch will live on when Pebble’s servers shut down” that had good news for owners of the Pebble smartwatch:
But now that Pebble has been acquired by Fitbit and is presumably nearing the end of its life, Pebble users fretted that their watches would cease to work once Pebble dies. That’s not the case.
Pebble just rolled out an iOS and Android update that frees its watches from cloud-based online servers. That means when Pebble goes offline, your watch will still work.
Coincidentally, this was one year to the day since I posted “Google’s Parent Company is Stirring Up a Hornet’s Nest”, which talked about Nest’s decision to brick the Revolv home automation hub rather than continue to support them. Fitbit’s decision was a refreshing departure from the attitude demonstrated by Nest (and lampooned by xkcd above). The punchline was going to be: basic human decency seems to be a disruptive tactic these days.
And then I launched Twitter Monday morning:
By this point, I would assume Sunday night’s, incident needs no explanation on my part. Details are still coming out, but regardless of what develops, United Airlines is the loser in this scenario. There’s an old saying is that there’s no such thing as bad publicity.
The old saying is wrong:
The tweet above has plenty of company in the twitterverse, none of it flattering to United or beneficial to its share price. Tweets like this haven’t helped:
The perception that sticks is that an older man, a doctor, was violently removed from a plane in order to allow United to get four of its flight crew to Louisville and United’s CEO is upset about having to “…re-accommodate these customers” (not exactly what’s said, but certainly what will be taken away from that garbled message). Additionally, the poor job done on that earlier message completely undercuts the perceived sincerity of the latter one:
Given United’s past problems with customer service, one might expect more effort would have been spent to prevent incidents like this and they would have been better prepared for dealing with the aftermath of something that did go badly.
Wrong on both counts.
An excerpt from a recent interview of Oscar Munoz (United’s CEO) on Business Insider makes the situation all the more egregious:
Here, in Chicago, it’s miserable because if you don’t leave by a certain time, you are just dead. “I’m going to get there and there are going to be a billion people and the damn TSA line.” By the time you get to sit on one of our seats you are just pissed at the world.
So how do we make all of that a little bit easier? This is the thing. You’ve got that broad issue of anger and anti-industry noise. We’ve lost the trust and respect of the broader public, and so every action we take, they don’t particularly like, they see it negatively. We have to work on that broad communication. I am going to do it at this airline and allow myself to differentiate in the flight-friendly mode so that people don’t immediately have that visceral reaction.
Dragging people off a flight (literally) probably doesn’t fit into the mold of a “flight-friendly mode”.
So I will return to my original punch line: basic human decency seems to be a disruptive tactic these days.
Ten days ago, when I wrote the post “Uber and the Cost of a Culture of Corruption”, I said that assuming there will be negative consequences (both legal and financial) from the incidents in the news, then it is in Uber’s best interests to fix the problem that led to them in the first place. The negative consequences are now becoming visible in the form of people abandoning ship.
Over the weekend, Uber’s president, Jeff Jones, resigned with the following statement:
I joined Uber because of its Mission, and the challenge to build global capabilities that would help the company mature and thrive long-term.
It is now clear, however, that the beliefs and approach to leadership that have guided my career are inconsistent with what I saw and experienced at Uber, and I can no longer continue as president of the ride sharing business.
There are thousands of amazing people at the company, and I truly wish everyone well.
Travis Kalanick’s announcement to Uber’s employees, while factually accurate (the decision did come after the announcement of the search for a COO), doesn’t quite convey Jones’ reasons for leaving:
Team,
I wanted to let you know that Jeff Jones has decided to resign from Uber.
Jeff joined Uber in October 2016 from being CMO at retailer Target. In 6 months, he made an important impact on the company—from his focus on being driver obsessed to delivering our first brand reputation study, which will help set our course in the coming months and year.
After we announced our intention to hire a COO, Jeff came to the tough decision that he doesn’t see his future at Uber. It is unfortunate that this was announced through the press but I thought it was important to send all of you an email before providing comment publicly.
Rachel, Pierre and Mac will continue to lead the Global Ops teams, reporting to me until we have signed a COO. Troy Stevenson, who leads CommOps, and Shalin Amin who leads brand design will report to Rachel Holt. Ab Gupta will report to Andrew MacDonald.
Thanks,
Travis
Jones is not the only Uber executive to resign this weekend. Brian McClendon, vice president in charge of Uber’s mapping, is “…leaving to return to his hometown in Kansas”.
These resignations are also not the only recent executive casualties. Ed Baker, vice president of product and growth, had also announced his departure earlier this month amid questions regarding his conduct with other Uber employees. This came after senior vice president of engineering Amit Singhal was asked to resign when it was discovered that he failed to disclose that he was investigated for sexual harassment while at Google.
It’s cliché to talk about people as assets, but for companies like Uber, their talent really does comprise the majority of their value. While the media will take note of high-profile departures like these, it would be a mistake to consider them the entirety of the damage. How many lesser known employees have left or will be leaving as a result of the recent scandals? How much potential talent will pass by opportunities at Uber due to what’s happened? In particular, how much harder will this make Kalanick’s search for a Chief Operating Officer who can turn things around?
If the talent drain is not quickly plugged, what happens to the quality of Uber’s service?
This situation perfectly illustrates the theme of organizations as systems. Uber’s software and business model have done well for it, but the culture created by the lack of leadership and lack of ethics of its management may well sink it. One bad component can bring down a system, whether software or social. The tragedy is that the innocent would be harmed along with the guilty.
Even before I hit the “Publish” button on Monday’s post, “Regulating Software Development”, I had already started composing this post in my head. In that post I had used the words “corrupt culture” in passing. I needed to expand on that, because I believe that’s what lies at the heart of Uber’s cascading collection of scandals.
Uber’s business model has always displayed a certain flexible attitude towards government regulation. Greyball represented a departure from dancing on the line to barging over it. Caught with their hand in the cookie jar, Uber has now announced “We are expressly prohibiting its use to target action by local regulators going forward”. I doubt this act of contrition on their part will be deemed sufficient.
In this environment, Susan Fowler’s account of her time at Uber becomes less of a “how could they be so stupid” story and more of a foregone conclusion. When, to all appearances, violating the law is part of your business model and you’re building software intended to thwart enforcement of the laws you’re violating, your moral authority is rather thin. In this type of culture, I’d imagine things like unwanted sexual advances and retaliation aren’t seen as a big deal, rather business as usual. Crossing lines, like other activities, becomes easier with practice.
Assuming that there will be negative consequences (both legal and financial), from these incidents, then it is in Uber’s best interests to fix the problem that led to them in the first place. This means radically changing Uber’s culture, otherwise new problems will continue to arise. Uber’s CEO has announced that the company is looking for leadership assistance:
“This morning I told the Uber team that we’re actively looking for a Chief Operating Officer: a peer who can partner with me to write the next chapter in our journey,” Kalanick said in a statement on Tuesday.
It remains to be seen whether this will represent a radical change in leadership or not. Anything less than a radical change will be unlikely to affect the current culture which appears to be a deeply entrenched. Debbie Madden, CEO of Stride, published an open letter to Uber’s Travis Kalanick on Wednesday. In “Dear Travis Kalanick: Here’s What You Must Demand From Uber’s New COO”, she noted that “Uber’s culture is broken and you need help to fix it”. She outlined seven steps to do just that:
Step 1: Change Uber’s core values
…
Step 2: Kill Greyball
…
Step 3: Adopt a zero-tolerance harassment policy and fire offenders
…
Step 4: Hire a strong head of HR and an employment lawyer and educate employees
…
Step 5: Fire or PIP each manager and HR employee who turned a blind eye
…
Step 6: Shift focus from individual productivity to team productivity
…
Step 7: Change your recruiting process
…
Uber isn’t the only organization in trouble due to a troubled culture. Volkswagen is in the same boat and it isn’t over yet. It’s reported that the pollution hidden by their cheating on emissions testing could contribute to the early death of 1,200 Europeans. It’s a solid bet that there will be more litigation to come.
Uber hasn’t killed anyone as a result of their corporate culture, but with their interest in self-driving vehicles, we should all be rooting for a turn-around in the ethics department. Uber can only exist in the future by eliminating the Uber of the past.
My last post, “Defense Against the Dark Art of Disruption”, went into some detail about notable failures in customer-experience for 2016. This week, however, I ran across a counter-example (h/t to Tim Worstall) showing that a little social media awareness and a customer-centric culture can make magic:
A baby products company is launching a special run of ‘little blue cups’ for a 13-year-old boy with autism following a global appeal by his father.
Ben Carter, from Devon, will only drink from a blue Tommee Tippee cup, prompting father Marc to put out an appeal on social media after becoming concerned the cup was wearing out.
Ben would refuse drinks that were not in the cup and had been to hospital with severe dehydration.
His father, tweeting as @GrumpyCarer, prompted people across the world to look through their cupboards for identical cups or to spread the #cupforben message. His request was retweeted more than 12,000 times.Tommee Tippee, based in Northumberland, said it was nearly 20 years since it had manufactured that product, but has now rediscovered the design and found the mould used to make the two-handled originals, stored in a usable condition in China.
It has said it will make a run of 500 cups to ensure ‘that Ben has a lifetime supply and that his family won’t ever have to worry about finding another cup’.
While I don’t know what it cost them to find the molds and run a one-off batch of cups, I suspect that the value of the positive global media coverage should substantially offset it. As a father, I know that the gesture was priceless.
Win-win.
My first post for 2016 was titled “Is 2016 the Year for Customer-Focused IT?”. The closing line was “If 2016 isn’t the year for customer-focused IT, I wonder just what kind of year it will be for IT?”.
I am so sorry for jinxing so many things for so many people. 🙂
So far, the year has brought us great moments in customer experience like:
Apple, of course, probably won the prize with their “courageous” iPhone 7 rollout:
Using “courage” in such a way was basically a lethal combination of a giant middle finger mixed with a swift kick in the nuts, all wrapped in a seemingly tone-deaf soundbite. This is the kind of stuff critics dream about.
Because Schiller said exactly what he said, he left the company open to not only mockery, but also bolstered a common line of criticism that often gets leveled upon Apple: that they think they know best, and everyone else can hit the road. You can argue that this is a good mentality to have in some cases — the whole “faster horse” thing — but it’s not a savvy move for a company to say this so directly in such a manner.
Apple then continued it’s tradition of “courage” with the new MacBook Pro models.
So, is there a point to all this?
Beyond the obvious, “it’s my site and I’ll snark if I want to”, there’s a very important point. Matt Ballantine captured it perfectly in his post, “Ripe for Disruption”: “You’re less likely to be disrupted if you are in sync with your customers’ view of your value proposition.” His definitive example:
I think that most of the classic cases of organisational extinction through disruption can be framed in this way: Kodak thought their value was in film and cameras. Their customers wanted to capture memories. Kodak missed digital (even though they kind of invented it).
The quote bears repeating with emphasis: “You’re less likely to be disrupted if you are in sync with your customers’ view of your value proposition.” What you think your value proposition is means a whole lot less than your customer’s perception of the value of what you’re delivering. This is a really good way to poison that perception:
https://twitter.com/jetpack/status/790931790961729536Disappointment, betrayal (perception is reality here) are not conducive to a positive customer experience. Customer acquisition is important, but retention is far more important to gaining market share (h/t to Matt Collins). The key to retention is to relate to your customers; understand what they need, then provide that. Having them pay for what’s in your best interest, rather than theirs (hello Kodak), is a much harder sell.
What’s the biggest problem with technical debt?
https://twitter.com/jetpack/status/724637235459547136In my opinion, the biggest problem is that it works. Just like the electrical outlet pictured above, systems with technical debt get the job done, even when there’s a hidden surprise or two waiting to make life interesting for us at some later date. If it flat-out failed, getting it fixed would be far easier. Making the argument to spend time (money) changing something that “works” can be difficult.
Failing to make the argument, however, is not the answer:
Brenda Michelson‘s observation is half the battle. The argument for paying down technical debt needs to be made in business-relevant terms (cost, risk, customer impact, etc.). We need more focus on the “debt” part and remember “technical” is just a qualifier:
https://twitter.com/jetpack/status/703327984107782144The other half of the battle is communicating, in the same business-relevant manner, the costs and/or risks involved when taking on technical debt is considered:
Tracking what technical debt exists and managing the payoff (or write off, removing failed experiments is a reduction technique) is important. Likewise, managing the assumption of technical debt is critical to avoid being swamped by it.
Of course, one could take the approach that the only acceptable level of technical debt is zero. This is equivalent to saying “if we can’t have a perfect product, we won’t have a product”. That might be a difficult position to sell to those writing the checks.
Even if you could get an agreement for that position, reality will conspire to frustrate you. Entropy emerges. Even if the code is perfected and then left unchanged, the system can rot as its platform ages and the needs of the business change. When a system is actively maintained over time without an eye to maintaining a coherent, intentional architecture, then the situation becomes worse. In his post “Enterprise Modernization – The Next Big Thing!”, David Sprott noted:
The problem with modernization is that it is widely perceived as slow, very expensive and high risk because the core business legacy systems are hugely complex as a result of decades of tactical change projects that inevitably compromise any original architecture. But modernization activity must not be limited to the old, core systems; I observe all enterprises old and new, traditional and internet based delivering what I call “instant legacy” [Note 1] generally as outcomes of Agile projects that prioritize speed of delivery over compliance with a well-defined reference architecture that enables ongoing agility and continuous modernization.
Kellan Elliot-McCrea, in “Towards an understanding of technical debt”, captured the problem:
All code is technical debt. All code is, to varying degrees, an incorrect bet on what the future will look like.
This means that assessing and managing technical debt should be an ongoing activity with a responsible owner rather than a one-off event that “somebody” will take care of. The alternative is a bit like using a credit card at every opportunity and ignoring the statements until the repo-man is at the door.
Why would anyone worry about user experience for anything that’s not customer-facing?
This question was the premise of Maurice Roach’s post in the Zühlke blog, “Empathise with your users or you won’t solve their problems”:
Bring up the subject of user empathy with some engineers or product owners and you’ll probably hear comments that fall into one of the following categories:
- Why do we need to empathise when the requirements tell us all we need to know about the problem at hand?
- Is this really going to improve anything?
- Sounds like an expensive waste of time
- They’ll have to use whatever they’re given
These aren’t unexpected responses, it’s easy to put empathy into the “touchy feely”, “let’s all hug and get along” box of product management.
Roach’s answers:
Empathy does a number of things, but mainly it increases the likelihood that the delivery team will think of a user and their pain points when delivering a feature.
If an engineer, UX designer or product owner will has sat with a user, watched them interact with their current software or device they will have an understanding of their frustrations, concerns and impediments to success. The team will be focused on creating features with the things they have witnessed in mind, they’re thinking about how their software will affect a human being and no amount of requirement documentation will give them that emotional connection.
…
Empathy can also help to develop a shared trust in the application development process. The users see that the delivery team are interested in helping to solve their problems and the product delivery team see the real users behind the application.
All of these are valid reasons, but the list is incomplete. All of these answer the question from a software development point of view. To his credit, Roach pushes past the purely technical aspects into the world of the user. This expanded exploration of the context is, in my opinion, absolutely essential. What’s presented above is an IT-centric viewpoint that needed to be married with a business-centric viewpoint in order to get a fuller picture.
Nick Shackleton-Jones, in his post “The Future Is… Organisational Usability!”, outlined on the problem:
Here’s how your organisation works: you hire people who are increasingly used to a world where they can do pretty much anything via an app on their iPhone, and you subject them to a blizzard of process, policy, antiquated systems and outdated ways of working which pretty much stop them in their tracks, leaving them unproductive and demoralised. Frankly, it’s a miracle they manage to accomplish anything at all.
As he notes, enterprises are putting a lot of effort into digital initiatives aimed at making it easier for customers to engage with them. However:
…if we are going to be successful in future we need to make it much easier for our people to do their jobs: because they are going to be spending less time with us, and because we want engagement and retention, and because if we require high levels of capability (to work our complex systems) then our resourcing costs will go through the roof. We have to simplify ‘getting stuff done’. To put it another way: in an ideal world, any job in your organisation should be do-able by a 12-yr old.
While I disagree that “any job in your organisation should be do-able by a 12-yr old”, Shackleton-Jones point is well-taken that it is in the interests of the business to make it easier for people to do their jobs. All aspects of the system, whether organizational, procedural or technological, should be facilitating, not hindering, the mission. Self-inflicted, unnecessary impediments are morale-killers and degrade both effectiveness and efficiency. All three of these directly impact customer-experience.
While this linkage between employee user experience and customer experience makes usability important for line of business systems (both technological and social), it has value for peripheral systems as well. Time people spend on ancillary tasks (filling out time sheets, requesting supplies, etc.) is time not spent on their primary duties. You may not be able to eliminate those tasks, but you can minimize their expense by making them quick and easy to complete. The further someone’s knowledge/skill/experience level gets from “do-able by a 12-yr old”, the bigger the savings by paying attention to this.
Rather than asking if you can afford to pay attention to user experience, you might want to ask whether you can afford not to.
Form Follows Function 