Lately, I've been having a lot of discussion with various folks on my thoughts on the future of the automotive industry.
Within the next 10 years, we will see a huge transformation in the industry and how consumers use cars.
Every manufacturer has announced or is working on some variant of ride sharing and autonomous driving.
Driverless cars could imminently be operating on London's streets, after Nissan announced it had been cleared by the UK government to commence limited trials.
While Google has been testing its own autonomous vehicles on public roads near its Californian headquarters, Nissan claimed that its driverless cars will be the first to hit public roads in Europe—if, that is, the Japanese manufacturer receives final approval from an undisclosed local authority in the UK's capital.
DETROIT—Volvo is among the leaders of the pack of automakers when it comes to autonomous driving. The various advanced driver assists in its current XC90 and S90 are some of the best we've tested, and the carmaker recently linked up with Uber to develop redundant systems in self-driving cars. But before there was the Uber collaboration, there was Drive Me, a multiyear research program that the company will use to look at how it, as a car maker, can contribute to a "sustainable society." In the video above, we speak to Trent Victor, senior technical leader of crash avoidance at Volvo, about the program.
Volvo chose this year's North American International Auto Show to hand over the first set of keys in the Drive Me program. It's in the process of recruiting 100 families in Gothenburg, Sweden, but the first lucky family is the Hains. Over the next few years, the Hains and the other participating families will be testing out a number of different research vehicles like the XC90 SUV seen in the video. In addition to testing out new iterations of self-driving systems, the vehicles will also be fitted with sensors and data loggers in the cabin to monitor the occupants.
GM and Lyft, in whom they invested $500m:
General Motors Co. and Lyft Inc. within a year will begin testing a fleet of self-driving Chevrolet Bolt electric taxis on public roads, a move central to the companies’ joint efforts to challenge Silicon Valley giants in the battle to reshape the auto industry.
Cadillac (GM) has started their BOOK program:
A flat monthly fee of $1,500 eliminates the hassles of car ownership so members can experience uninhibited driving. Membership is month-to-month with no long-term commitment required. Members can use a mobile app to reserve vehicles that will be delivered to their specified locations via a white-glove concierge service. Certain location restrictions apply. Members will have access to the current year Platinum Level Trim Cadillacs, including the XT5, CT6, Escalade and V Series. Registration, taxes, insurance and maintenance costs are included in the monthly rate and there is no limit on mileage.
And of course, there is Tesla, Google, Nvidia.
While there has been a lot of skepticism with many whom I've talked to, the reality is that we are at a convergence of technology and engineering that will transform the automotive industry -- and many ancillary industries -- in the next 10 years. Leaders in the auto industry really deserve some credit given that we've seen industries like music and television wholly unprepared for the transition wrought upon them by technology; by and large it seems clear that the industry can see the shift and have invested in shaping their futures.
This moment is the convergence of computer vision, improvements in mobile computing, and maturity in the field of neural networks and deep learning -- the latter two are now commodities that anyone can take advantage of for pennies on either Amazon or Azure. As we saw with the shift with enterprise infrastructure once compute became a commodity, so too will we see a shift in the prevalence of "AI" given the advancements and commoditization of these capabilities.
There are powerful business drivers, of course. From the perspective of companies like Google, it allows them to achieve higher engagement and serve more ads. It also opens up new models of revenue and advertising; imagine a smart car that can suggest "sponsored" restaurants in the area if you are heading out for a meal. For companies like GM, Nissan, Volvo, etc., it is an evolve or die scenario as the industry is transformed.
The degree of transformation in this industry will be massive. The first wave will be an increase in programs like BOOK that will continue the trend of unbinding the need for transportation from the need of ownership. We are already seeing this with the tremendous growth of Uber and Lyft in the last few years. BOOK is currently only available for Cadillac's most premium cars with "white glove" concierge services -- and the price reflects that! However, I think we will see this model move downmarket.
One might fairly ask how this is any different from renting a car. I think there's one key difference: the model is to "rent" directly through the manufacturer and this is a precursor to an all new model. In a future when autonomous driving is mainstreamed, these services will reach their full potential whereby manufacturers will sell services directly to consumers. You won't buy or lease a car, but rather summon an autonomous car from a local hub that will come and transport you for your trip in much the same way that you would hail an Uber ride. It is this transformation that every manufacturer sees and it is this inevitability that they are prototyping and investing in.
In some sense, Tesla has been at the forefront of some aspects of this model. Obviously, Autopilot is one of the most competent semi-autonomous driving systems currently on the market. But beyond that, Tesla has already done away with the traditional dealership model, though it has been as a result of legal challenges from entrenched dealerships. While Tesla has been fighting these legal battles, traditional manufacturers like GM, Renault-Nissan, Ford, etc. have been sitting on the sidelines, waiting to see the result and observing. After all, there is no logical reason why Toyota can't sell directly to you except that there is an entrenched model and legal framework that prevents them from doing so. But they have been preparing, learning, and now experimenting as we see with BOOK.
With the inevitable reduction in car ownership, we can expect quite a bit of fallout across many industries.
For starters, the model of automotive insurance will need to change. Consumers may carry additional personal injury insurance, but the cost of insurance will be shifted to the service provider in much the same way that the insurance on your Uber ride is the responsibility of the Uber driver.
Automotive dealerships will also need to evolve. It is likely that we will see dealerships transform into hubs that largely provide service and maintenance as well as a central distribution point (though a fully distributed model is certainly also possible). Many dealerships will likely go out of business in this process as profitability drops and more competitive options arise for manufacturers.
Used car dealerships and the entire infrastructure supporting that will need to evolve as there will be less buyers of used cars. The value of used cars themselves may take a large hit as the market of buyers shrinks and the cost of ownership increases.
Municipalities will need to rethink their model of infrastructure planning. A township in New Jersey just last year piloted a program that reimbursed for Uber rides instead of investing in a new parking lot. What effect will a new model have on bond commitments related to existing infrastructure? How will it affect zoning and planning? Municipalities will also have another challenge: how will autonomous vehicles affect their revenues from traffic violations when these cars will obey posted speed limits and stop at every stop sign and red light? What happens when no one needs to park at meters because the cars will operate on-demand? How will they make up this gap in their revenue stream?
Small businesses like car washes and even big businesses like auto parts stores will need to plan for a future where ownership decreases. It is likely that most will go out of business, but more likely in a time span of 15-20 years.
There will be new industries and new opportunities as well that will transform local businesses. For example, an autonomous food or parcel delivery vehicle can be configured very differently from any typical vehicle designed to transport humans. Will we have a need for pizza or takeout delivery drivers when an autonomous vehicle can deliver the food more cost effectively? It is not likely that a small local restaurant would buy these vehicles, but rather rent them from a vendor that specializes in these vehicles and increase their delivery capacity on demand.
Manufacturers themselves will need to figure out how to shift their business and resource models in a future where the ratio of cars to riders is significantly lower. How will it affect their current investments in manufacturing facilities? What about their commitments to their human resources? What will the effect be on their current real estate investments be? What types of resources will they need in the future when they transition into not only a manufacturer, but also a service provider? Or will the model be altogether different and will they spin off the service provider from the manufacturer? Uber will be redundant when manufacturers can provide the services directly without a middleman much like how streaming has shifted the relationship between content produces and consumers. Perhaps Uber will become more like a Hulu where it provides a consortia a platform for managing services. Tesla is already heading down this route.
Maybe a more important question for manufacturers is how will the market shift once ownership is a thing of the past? Will people still care about brands? Or will they care more about the purpose? I need to transport 6 adults. I need to transport sheets of plywood and drywall. I want something a bit flashier for my date. By and large, I think most folks don't care what their Uber driver is driving; rather they care about the class of vehicle: luxury for a high end experience, mini-van or SUV for carrying people and luggage to the airport, typical sedan for lowest cost. Perhaps we may see the death of a few brands as the market contracts in reaction to this new model.
The fossil fuel industry will also be impacted as transportation models become more efficient (forget about electrification) and less cars are needed to meet the same demand. For example, we could see lower priced services that allow multiple riders per vehicle based on smart routing. We could even see models like we see in the airline industry where smart routing will pool and "transfer" riders to maximize efficiency and provide a lower cost service. Google already has a patent for smart pickup and dropoff locations. It's not difficult to make the leap that they could more intelligently route pickups and dropoffs to maximize efficient routing of the vehicles matched to demand. "Passenger Charles Chen, please exit the vehicle here. A blue Prius with license plate 247X3K will be here shortly to continue your trip. Thank you for using Google Transit; you saved $3.50 and 4000 grams of CO2 by using Google Transit Eco today! You should arrive at your destination in 15 minutes; you are still on time for your 6:00PM appointment; would you like to stop at Starbucks for coffee first?"
In discussions with skeptics, one argument that comes up is the ownership experience. There are various aspects of this such as status or pride of ownership (Americans do have a strong history of sentiment attached to their cars) or even conveniences such as keeping your things in your car. But I think that this, too, will change culturally as a matter of convenience in much the same way that we have shifted on from physical media for music and video. My 2016 Mazda CX-9 doesn't even come with a CD player. How did this happen? After all, there is a deep culture associated with physical media from vinyl to mix tapes even to CD jackets. The same with books; there is a certain experience associated with reading a physical book that is strongly ingrained into our culture. Libraries, the smell of books, taking notes and putting dog ears in pages of a book, passing a book down from generation to generation. And yet, e-books are here to stay despite their limitations and restricted ownership models (Amazon can wipe your account at any time, after all). The answer is part convenience and how it is enabled by technology; with the availability of always connected devices, the need to even carry digital media around is redundant. Why do so when you can stream any song, wherever you may be? I've seen a shift even in flights where airlines are no longer investing in screens on their planes and instead investing in streaming to personal devices.
It is not the extension or progression of a model such as renting a car, as suggested by one of my counterparties, but rather an all new model. In much the same way, Uber is not an extension of the model of taxis; it entirely disrupts the business model by removing the barrier of medallions and licenses. Even if you slapped the Uber app on top of existing taxi businesses, it would not be the same model. Likewise, Airbnb is not an extension of the hotel business model; it is an entirely new model that disrupts the existing business model. The shift we will see in the automotive industry is not an extension or progression of an existing model, it is a wholly new model which will come to dominate how we consume transportation services.
It will be far more convenient for a generation of consumers who have no interest in maintaining cars. For parents that are too busy to shuttle their kids around to this practice or that lesson. For business travelers who need a vehicle all over the country but don't want the hassle of booking rentals. For restaurants who can rent delivery capacity on demand instead of hiring drivers. For a generation that will grow up with devices and have no desire to suffer boredom and tediousness when they have a choice. The spaces that we reserve for parking cars can be used for better purposes. Townships will not need make heavy capital investments in wasted "dead zones" like parking decks.
I look forward to this future and it will be interesting to observe what other types of fallout we see from this shift in the next decade.
If you're like me, you've noticed that organic milk tends to have a longer shelf life and tastes better so I tend to spend the extra money because aside from our 1 year-old, the family drinks milk erratically and I prefer the taste. But are these properties of the organic nature of the milk? It turns out that there is a simple explanation for both that is quite interesting and may (or may not) change your mind on spending extra on organic milk.
First is the question of longer shelf life. This is actually a result of logistics. There are fewer farms providing organic milk so it often has to travel further and undergoes a high temperature pasteurization process that kills all bacteria:
The process that gives the milk a longer shelf life is called ultrahigh temperature (UHT) processing or treatment, in which milk is heated to 280 degrees Fahrenheit (138 degrees Celsius) for two to four seconds, killing any bacteria in it.
Compare that to pasteurization, the standard preservation process. There are two types of pasteurization: "low temperature, long time," in which milk is heated to 145 degrees F (63 degrees C) for at least 30 minutes*, or the more common "high temperature, short time," in which milk is heated to roughly 160 degrees F (71 degrees C) for at least 15 seconds.
The different temperatures hint at why UHT-treated milk lasts longer: Pasteurization doesn’t kill all bacteria in the milk, just enough so that you don't get a disease with your milk mustache. UHT, on the other hand, kills everything.
Interestingly, UHT treated milk no longer needs refrigeration (prior to opening). Your grocer keeps it refrigerated as a matter of consumer expectation (how silly we Americans are).
The answer to the second question actually arises from the answer to the first. The process of UHT actually changes the chemical nature of the milk by breaking down some proteins and cooking some of the sugars. Organic milk tastes different not because it's organic, but because of the pasteurization process which happens to change some of the molecular structure of the milk:
UHT sweetens the flavor of milk by burning some of its sugars (caramelization)....UHT also destroys some of the milk’s vitamin content—not a significant amount—and affects some proteins
So there you have it; organic milk does indeed taste different from non-organic milk, but it's not a placebo effect and it's not because it's organic. If you're a European in the US and you find our milk tastes funny, try the organic milk.
I may take up this article on giving non-organic UHT milk a try.
One of the key takeaways, for me:
He was challenging me because he expected more from me. When somebody cares about you, that’s when they challenge you. When they don’t care about you, they ignore you. That’s when you should worry.
It is natural for people to react negatively to critical feedback, especially when that feedback addresses a shortcoming or a weakness in some work, some effort that one has invested heavily in.
It is important to step back and detach the emotional aspect of coming up short of perfection and consider whether this critical feedback is dismissive or whether it is a revelation of some unmet potential that we, ourselves, have not yet recognized.
The whole thing is a good read and great piece of motivation to understand what it takes to succeed.
Poorly Controlled Scope
Scope is enemy number 1; it is the amorphous blob that threatens to consume and grow until it is an uncontrollable monster, swallowing all of your carefully planned man hours.
Increases in scope are often the result of failure to manage the customer and expectations. In any given project, there are only so many levers that can be used to control the successful delivery and it is up to the skilled project manager or client interface to toggle these levers of team size, timelines, requirements, and so on.
The worst is when growth of scope originates from within the team as it is a form of cancer that only causes teams to compromise on quality to meet timelines promised to the customer. You see, when scope creep originates from the customer, there is a certain expectation that of course, costs will increase or timelines will need to be shifted. After all, they are asking you to do more than was initially agreed upon. But when new scope originates from the team itself, the customer will not readily accept this delay.
The cost of scope increases is often not well accounted for. A change that takes a developer 2 days to make will cause ripples that force test teams to adjust their scripts, documentation teams to update their documents, and possibly trigger expensive regression testing.
Smart teams and leaders will understand that these can be controlled, in many cases, by simply creating a roadmap and understanding that desired features and capabilities that don't fit into existing timelines can be added to "v.next".
(Over) Reliance on Manual Effort
To a certain extent, software engineering requires raw manpower to execute large projects that require many hundreds of thousands of lines of code and lots of moving parts.
But within the lifecycle of a project, there are many activities that can be simplified by the use of automation. Teams must judiciously balance the cost and effort of the automation versus the savings gained, but more often than not, even a little bit of automation is better than none. It's crazy to think that it was once the case that all phone calls were manually routed between parties.
Nowadays, the idea seems crazy! Imagine if the billions of people on this Earth were to rely on the same processes to connect phone calls today!
Testing is a great example where failure to automate creates a bottleneck to progress. It increases the cost of changes and bug fixes because it increases the cost of regression testing. Make the regression testing virtually free and the cost of introducing changes (whether small scope creep for critical bug fixes) is decreased dramatically.
Technologies like Selenium WebDriver and Visual Studio's built in tooling make it possible to achieve significant gains in productivity when it comes to testing. Don't let excuses hold your team back.
One skilled test automation engineer is worth her weight in gold!
Poor Communication and Collaboration
Strong and open channels of communication are critical for the success of projects, especially so when some or all of the resources are remote.
The flow of information and feedback from the customer to the design and engineering teams must be swift and clear so that expectations are known and any roadblocks can be communicated back. Engineering teams will often have insights into the challenges and nuances of a customer's input and it can be dangerous to agree to timelines or make promises without clearly engaging the teams executing the implementation. Ideas that seem simple on paper or in concept can require massive engineering changes or sacrifices to achieve and not properly estimating this work is a common pitfall.
Demarco and Lister's Peopleware offers excellent insight into how to foster better communication and collaboration between teams.
Often, one of the simplest solutions is to simply talk to each other instead of using emails, chat messages, and worst of all: assumption ("Oh, I thought you already knew that"; we've all heard that one before!). Get in front of a whiteboard and draw out ideas, deadlines, goals, and so on. Go out to eat lunch together. Plan team activities that engage everyone. Make sure that everyone is on the same page on a professional level as well as a personal level.
Not Keeping Your Eyes on the Prize
It's easy for a team to get distracted and lose their focus on the goals of the project and the conditions of victory.
It is therefore critical that teams focus on a goal-oriented approach to the delivery of software projects. This is a mind-set that scales up from daily scrums to weekly reviews and so on. Even a short coffee break can be used to re-orient a wandering team member towards the goal posts. Small, daily victories can help teams build momentum and continuously align towards the long term milestones.
It's important that individuals and teams know, at any given time, what is expected of them and what the priorities of the project are. This allows individuals to make decisions autonomously and with little managerial overhead as they understand how to align themselves with the goals of the project and team. Clear communication of goals allows any misunderstandings to surface early by pinning expectations to milestones -- be they simply daily ones, weekly ones, or project level milestones.
Teams and leaders that are poor at communication and collaboration will often lose their focus on the prize because there is a lack of understanding about shifting goals and priorities; there is a dependence on assumption instead of clearly aligning all parties to a set of well-defined conditions of victory. These anti-leaders will focus on the tasks instead of the goals; it should be the other way around - focus on the goals and derive your tasks from them.
Unwillingness to Compromise
Teams must always be ready to compromise because this is the real world where timelines and successful delivery of usable software matters, but people also have families and life outside of work. Unplanned circumstances arise that challenge the best laid blueprints.
If it is discovered that a feature will negatively impact performance of the system in the current architecture, compromise must be made on either the feature or the timelines to ensure that the desired capability can be delivered as usable software.
If unforeseen circumstances eat into the project timelines, compromise must be made to clearly redefine the scope and conditions of victory.
This is the real-world; man-hours are not unlimited and an unwillingness to compromise when necessary leads to poor quality as a team pushes to make up time.
In many cases, it is a bitter pill to swallow as it may mean telling a customer that a feature must be delayed or built into the next release, but I find that more often than not, openness and clearly communicating these issues as early as reasonable is productive and allows for rational decision making.
On a message board, I read a thread where a poster -- a research scientist -- was describing how he ended up becoming the defacto IT guy in his department simply because of his superior Google skills and willingness to Google for and apply solutions to fix issues for his colleagues.
This is something I've personally never been asked to do in an interview nor have I thought to ask others when I interview them, but it seems that being able to quickly Google and sift through results quickly to separate the wheat from the chaff is a skill that is supremely underrated in today's world of software engineering.
The fact is that developers and technology specialists today need to deal with so many technologies and understand deep nuances, Google is often the only way that any of us can get anything done, especially with obscure errors and what not that Microsoft and SharePoint loooove to throw at you.
In fact, I'm quite surprised that I've never been asked to do a Google search speed and accuracy test.
How would one design such a test to be effective at measuring a candidate's speed and accuracy at using Google? Should the topics be relevant to the candidates job domain? Or should it be more generic? Should it test a candidate's knowledge of Google's advanced features?
One of the lessons I've been mulling about the past few weeks is the importance of scope when delivering software.
Delivery of software can be thought of as a balancing act between three buckets:
- Time - this is the schedule and how much time you have to complete the work.
- Money - this includes everything from spending on more resources, better resources, tooling support, and so on
- Requirements - this defines what you're building
These are the three basic buckets that constrain the scope of what can be done and they react to each other in different ways. If there are more requirements or the requirements are inflexible, then it necessitates more time or money or both. If both requirements and time are inflexible, then more money will be required to achieve the goals within those limits. If money is constrained (less resources), then you must allow more time to deliver the requirements or trim the requirements.
Having been in consulting and in software development, each project has different priorities on which is more important and these priorities drive the sizing, cost, and pace of the project.
But in software development, I think one thing that I think many folks -- even experienced individuals -- get wrong is the fixation and inflexibility on requirements. I think that requirements are really much more fluid in software development projects as compared to contract-driven consulting projects. The reason is simple: in software development, the assumption is that there will always be another version and there will always be another point release; this is exactly what roadmaps are for.
Plan a solid roadmap and if you don't get a particular feature or capability in this release, you and your customers should have a good idea of which release it will be in down the road.
Some tend to lose sight of this and think that all features must be shipped in a constrained timeline. I think this is a losing proposition that forces a team to compromise on quality by artificially forcing requirements into a release when the reality is that there are often really critical features that must be delivered and there are nice to have features that would be great if they could be delivered. Teams and leaders without discipline and a focus on the criteria of success will have a difficult time discerning the two and lump nice-to-haves right alongside the critical work items. This is a recipe for failed projects, missed deadlines, and poor quality.
The reality is that software rarely comes out fully baked unless you're NASA launching a space mission worth billions of dollars and you only get one shot; most teams are not under such otherworldly constraints. There will always be something that could be better or easier to use or some missing feature discovered along the way or some new idea. The trick for teams that succeed is being about to create boundaries on what is needed now.
Apple shipped 7 versions of iOS before adding support for third party keyboards and NFC.
NPR's first mobile site was terrible (I don't have a screenshot of it, unfortunately), but at least they shipped it and their audience could use it and now they've evolved it to be a clean, responsive web site.
Here's what the an early version of Facebook looked like:
Microsoft shipped Azure without support for virtual machines until 2013.
But what if instead of new features, we're talking about bugs or design flaw? There is an important calculus at play here and I think that one way to think about it is like this: if there is a bug or design flaw that is preventing increased growth in userbase or revenue, then that takes precedent over any other bug or design flaw that is in the shipped system. Think about it this way: if you ship four versions of the software with the bug or design flaw, chances are, you can probably ship a fifth without addressing it (of course, this is not always the case, especially if the flaw is related to security). But if a bug or design flaw is stopping adoption or holding back revenue, then that flaw automatically becomes the most critical focus for a release.
The point is that in software product development, more often than not, the winning strategy isn't to get it perfect (as much as Steve Jobs would have you believe that he got it perfect each time, the fact that there was a next release meant that it was intrinsically not perfect -- there was always something to improve or add); it's to get it out and ship it and acknowledge that there will be a future release to add features or other improvements. This really allows the team to focus on what's critical now and get it out the door and on time.
To that end, roadmaps are important as a communication tool and a lever for controlling scope because it gives customers visibility and a sense of certainty that while feature X is missing in this release, in 3 months, it'll be in the next point release. It's important because it helps manage the requirements bucket; without a roadmap, the tendency of the team and customers -- in my observations -- will be to assume that every requirement is critical. It's a purely psychological notion because the lack of the roadmap makes it difficult to allow the team to offload some ideas and lesser requirements so that the team can focus on the requirements that are truly necessary to ship it. Without the concrete notion of The Next Release, the feeling will be that everything must be crammed into this release.
Ultimately, I think that for software development teams to successfully ship software -- given the typical constraints of time, money, and requirements -- it's important to be able to take a critical eye to the requirements and really be able to categorize and define the scope of what is critical versus what is nice to have. A clear roadmap is an important tool to help teams organize work and thoughts as well as communicate intent to customers.
I was reading an NPR piece on worker burnout and some different tactics taken by different companies to deal with it and came across a very nice, concise definition:
Christina Maslach is a professor at the University of California, Berkeley, whose four decades of research on the subject helped popularize the term "burnout." Maslach says it's a loose term that encompasses a combination of work overload, lack of autonomy and reward and social and moral discord at work.
This sentence very concisely summarizes the key drivers of burnout and the factors at play are not as simple as "too much work".
The article also brings up an interesting observation (well, it's just the next few paragraphs):
Most burnout stems from interpersonal strife, but most employers see the solution as time off, she says.
If companies really want to know what's causing burnout in their workplace, Maslach says, they shouldn't just mandate more time off. They should assess the core problem, then design solutions to mitigate those issues.
"When it's time off, I mean, that might be time away from work," Maslach says. "Maybe you're addressing issues of exhaustion, but it's not really addressing what may be the problems at work."
Ultimately, a company, a project, a product -- it is the effort of many individual humans who must come together to fulfill a common goal. And when humans are involved, conflict is sure to arise. Obviously, you can still get things done when not all of your parts are in harmony, but isn't it much more enjoyable when they are?
I hardly consider myself an expert, but in my own experience, I've found that it's a good idea to work to reinforce those relationships between the people that comprise the team through team activities. A common one is eating together with one another or occasionally taking the whole office to lunch or dinner. It is especially important for management to be involved because it shows that the employees are valued as people and not just as fungible parts of a machine.
Andrew Fitzgerald comments in that NPR article:
One day I got called into the boss's office. I was thinking to myself "Shoot! What does this guy have on me now? They called me in just to tell me that they thought I was doing a good job and that they appreciate my work ethic. I didn't make a lot of money. The work was kind of tedious and repetitive but I could not tell you how good that made me feel. A little positive feedback from the higher ups goes a long way.
At IC, the development team is in a unique position because all of us work remotely and travel to Irvine. So we end up spending quite a bit of time together eating meals, going to the shooting range, kayaking on the weekends, and I'm planning on taking the team to an indoor climbing facility as well (I try to keep things fresh). I also try to make sure that everyone is taken care of; there is nothing I won't do from picking up lunch, driving a co-worker to a train station, picking up fruit for everyone to share, and so on. Not just because I manage them, but because I like and respect these guys as people first and foremost.
Even at a basic level, we sit together in the office and chit-chat from time to time about random things and watch random videos after we've been hacking away for 8 or 9 hours. When we are on site, not one member of the development team leaves before the others. Not because anyone is forced to stay, and not because we have some unspoken code about such actions or that we would shame anyone that did, but I think because we all feel that we are in this together and that truly, we have a common goal to achieve as a team.
And that is an important point, in my opinion, because too often, how leaders fail is by not aligning all of the cogs of the machinery towards a common goal. Most of the time, that simply involves clear and open communication about expectations, company goals, and an understanding of the priorities of the company or the team.
Like a train with two engines heading in opposite directions, failure by team leads to align the members of a team to a goal or failure by management to communicate expectations and priorities seems to lead to inaction, indecision, and conflict when team members are trying to pull in opposite directions. Ultimately, this just help feed into worker burnout.
In the wake of the Apple iCloud debacle, there has been a lot of discussion on what Apple has done wrong, what it could do better, and how this could have been prevented.
This is not a blog post about 2-factor authentication or proper implementation of authentication channels or how Apple should be more open in their dealings with the security community, but something more basic and common sense: give users more granular control on what gets backed up.
You will see in many discussions and comments to articles that there is quite a bit of "victim shaming".
But I think that this is quite unfair and I postulate that an average smartphone user has no idea that their photos are being synced to the cloud. It is far more likely that users had no idea that these photos and videos were synced to the cloud in the first place and even if they had an abstract idea that it was (for example, you take a photo on your phone and you can see it on your desktop later), they had no concrete idea of the implications (those photos are now resident in the cloud as opposed to transient).
It is easy to imagine that such things are obvious and should be trivially easy to configure and control to the end users, but I think that this is a poor assumption to make by anyone that is technically savvy; people like my mother and wife really have no idea about these things. My guess is that Jennifer Lawrence and Kate Upton simply had no idea that their photos and videos were sitting resident in the cloud and even if they did, they probably couldn't figure out how to get rid of them.
Some have said that this is not the fault of the OS makers or app makers. Google Photos, for example, gives you a very clear screen when you launch it for the first time asking you if you'd like to sync the files to the cloud. But one problem is that users may not actually read these things before agreeing. The other is that even after a user agrees, if the user decides that she wishes to change her mind, the setting is turned off from a screen that is three levels deep (launch Photos, click Menu, click Settings, click Auto Backup). While this is very obvious to some, to many -- like my mother -- this is an absolute mystery. She has no idea that it's syncing her photos and has no idea how to turn it off.
I think that there are many common sense solutions that can be implemented outside of the security measures implemented above to give users more granular control over their content.
Give Periodic Notifications to Update Privacy Settings
One simple idea is that say every three months, the phone prompts you with a notification in your notification bar:
This would allow users to periodically be reminded that things like automatic sync are on and that they have the option of turning them off. The user is free to ignore it, but it would give them at least a reminder that "Hey, I'm sending your stuff to the cloud, are you OK with that? Do you want to review your settings?"
Make Synchronization Explicit
One of the problems I have with Google Photos is that it's all or nothing by default. There isn't a middle ground that allows me to sync some of my photos as a default.
The user experience paradigm here would be much like that of Facebook where you can post photos by selecting them from your album to explicitly and with fine grain control what gets sent to the cloud. Likewise, iCloud and Google Photos would do well to allow a middle ground that gives users more fine grained control over what gets sent to the cloud instead of ON and OFF.
In discussions, some have said that this would present too high a burden on end users, but it seems to work fine for Facebook and I think that it would be relatively easy to implement in an easy to use manner:
If the user selects "Sync All", then all 20 new photos are synced to the cloud (be that iCloud, Dropbox, Google Drive, etc). If the user selects "Choose", the user is given a screen that allows the user to explicitly pick the ones to sync. The pick screen should prompt the user to "Ignore unselected items for future backup?" when selection is complete so that any unselected photos are simply ignored next time. If the user selects "Don't Sync", then do nothing.
A simple design like this still gives the user access to the convenience of cloud backups while giving them explicit, fine-grained control and acknowledgement that their data will be stored in the cloud.
The victim shaming is simply not warranted; whether these individuals should or should not have taken these compromising photos and videos is not the right question to ask. The right question to ask is whether Apple or Google should be automatically syncing them to a resident cloud storage without finer grained controls and explicit consent.
The principle is that any time you -- as it were -- voluntarily let up control.
In other words, cease to cling to yourself; you have an excess of power because you are wasting energy all the time in self defense.
Trying to manage things, trying to force things to conform to your will.
The moment you stop doing that, that wasted energy is available.
Therefore you are in that sense -- having that energy available -- you are one with the divine principle; you have the energy.
When you are trying, however, to act as if you were god, that is to say you don't trust anybody and you are the dictator and you have to keep everybody in line you lose the divine energy because what you are simply doing is defending yourself.
One mistake that I've been guilty of is to try to force things to conform to my will on various projects (I still do it to varying degrees!). It is usually with the best of intentions -- for a cleaner framework, a better product, a more efficient process -- but at the same time, it is true that a lot of energy is spent wasted in doing so.
What is the alternative, then?
I think Watts is right that a level of trust has to exist that the team around you can help you achieve your project goals. Instead of expending the energy in controlling the members of the team, spend the energy in building that trust through training, mentorship, guidance, and giving up not just control, but responsibility.
Sometimes that trust will be unwarranted, but sometimes, that trust will pay itself back many-fold.
Another finding was that the perception of heat could affect the participants’ emotions. The research team said that this is because emotions are more intense under bright light; thus, leading to the perception that light is heat, which can trigger more intense emotions.
The team also found that bright light affects the kinds of decisions people make. Since the majority of people work during the day under bright lighting conditions, the researchers noted that most daily decisions are made under bright light, which intensifies emotions.
Accordingly, they suggest that turning the light lower may help people make more rational decisions, not to mention negotiate better settlements in a calmer manner.
Taking emotion out of decision making is one of the most important skills one can develop and maybe it can be as simple as installing more ambient lighting and turning off those (ugly) fluorescent lamps overhead!