Work at home is best left to each individual to decide or manage for themselves. Dictates from management that work must be done a certain way usually reduce productivity. Fortunately my employer has a flexible work-at-home policy. It makes the small cubicles a little more tolerable. Most people are in the office every day anyway, but having the option makes a big difference in managing one's own work schedule and environment.
Collaboration is good, but often overrated. Those "random" interactions can quickly turn into a productivity-killing series of unwanted interruptions.
I have noticed that younger workers prefer the open, collaborative environment a little more. Maybe having less experience means you depend more on being able to immediately call on the guy in the next cube to help solve a problem, whereas more experienced workers have less need for this.
And by the way, Rick.. your employer only gives you 12 square feet of cube space? I hope that is a mistake, because that is ridiculously small, barely larger than a phone booth! I consider our cubes to be rather small at 64 square feet. I'd have to quickly find alternate working arrangements if somebody tried to squeeze me into a 12 sq foot cube five days a week.
I've further read that the or one of the main justifications Marissa Mayer used was that according to the VPN logs, a lot of the work at home folks weren't logging in very often or at all. The supposition was that if they weren't logging in, they weren't working.
There is some merit to that. While there have been times when I haven't checked email or anything all day while working at home, I generally do so several times a day. It likely was a case of, based on the type of work being done and the expected pattern of connected time, that it really looked like a a lot of people were abusing the system.
There are a few people that will abuse a system anytime they can get away with it. I think those people are the exception rather than the rule, but there are a lot more people that would end up slacking off if they didn't feel that the company cared or that their contribution did any good.
In reality, it is the deadwood that will tolerate those kind of policies. It's a great way to concentrate deadwood corporate robots and eject the creatives. But trust me, at one second after 5pm they'll be in the parking lot with their cellphone powered off.
Working in "the office" while writing software equals distractions every 45 minutes followed by at least 15 minutes to recover flow. Banning remote access sounds like an excuse for bad management. This is such a hypocritical move given Yahoo's history of offshoring engineering work. "Ah, you can't work at home... but you can work in India." Let's be honest, *if* Yahoo employees were motivated to innovate and they felt they *needed* to be in the office in order to accomplish that, they'd be in the office when it was most effective. We are dealing with adults here. This entire dictate reeks of bad, short-sighted, dilbertesqe management. I can pretty confidently predict that this will do nothing, nada, zero to fix Yahoo's innovation problems.
How about some real fixes. Number one, start by firing all your B and C players along with pretty much all middle management. Two, create strong non-perverse merit based incentives for employees to be individually driven to ambitiously pursue innovative product concepts. Three, lets see top executive management make some real sacrifices (in their pay and incentives especially), roll up their sleeves and get dirty for the long term game, and while they are at it they can take a blood oath to either succeed or fall on their sword. That's called real leadership. Something they appear to be completely lacking.
I have done a lot of engineering at home, and that part works well. BUT some parts of the development effort do work much better in a personal collaborative environment. But that may be only aan hour or two out of the whole project development time. Of course, thatnis in the area of industrial testing machines, which is a whole lot different than creating microcontrollers for internet enabled toasters. So really, much of the design engineering is easy to do at home, all of the debug and startup needs to be done where the hardware is accessable, and the concept development part does need a team effort.
Yes, that would be my conclusion too. You force everyone back to the old way of doing business, you might just lose as many productive people, at least, as you will be driving away the deadwood.
If it were me, I'd seriously consider moving on to greener pastures. (Of course, she might just want to get rid of me, so that's perhaps not a relevant point.)
Mayer knows what she is doing. She needs to make Yahoo perform and improved productivity is one of her goals. Perhaps a reduction of number of employees is another. But they need to be selective or they could lose some valuable people who might just go over to a competitor.
I am a Fellow level engineer. I walk through the office asking how things are going and giving advice how to tackle issues. 15 Minutes of my time can give a huge efficiency boost. I could not do this from home or when my collegues are at home.
This informal way of working requires physical presence.
I do attend many conference calls in various time zones but those are hardly ever as effective as face to face meetings.
It's all well and good to chime in on what you think but at the end of the day you are not running Yahoo. All of these comments should keep in mind that our opinion of what another company should and should not do is just our opinion. Maybe Yahoo just got tired of the down side to having employees telecommute.
It all depends on how you manage the WAH program. In Yahoo's case it have been completely mismanaged with employees not showing up on the campus for years and having very poor performance. When you get paid to work at home, you better perform. Once the deadwood has been cleaned out at Yahoo, I'm pretty sure the policy will change.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.