Slashdot Mirror
Cisco Exec: Turnover In Engineering No Problem
alphadogg (971356) writes The engineering reorganization currently underway at network giant Cisco Systems is intended to streamline product development and delivery to customers. That it is prompting some high profile departures is an expected byproduct of any realignment of this size, which affects 25,000 employees, says Cisco Executive Vice President Pankaj Patel, who is conducting the transformation. "People leave for personal business reasons," Patel said in an interview with Network World this week. "Similar transformations" among Cisco peers and customers "see personnel change of 30% to 50%."
I may just be interpretting this discussion different than everyone else here, but assuming every developer is happy with company, and company decides to implement a new development philosophy or production model (for strategic / financial / etc..) reasons, wouldn't it be sensible and actually expected that a non-trivial number of developers won't be happy with said changes?
For example, If my company went from Dev and IT groups to merging them into devops, some people are going to be rocking the idea, and a shit ton may be unhappy about the change and decide to move on. DevOps isn't any more or any less better for an employee, but it means a different set of tasks for that developer to live in. Maybe this change will significantly improve workplace productivity and the change isn't only merited, but essential for the company's survival. Same with, say dropping support for Windows/Linux/Mac/etcc OS's and just supporting a smaller set of OS's. Some would say there are valid reasons to adopt the standard (less IT burdens), and others who use said dropped OS's will be more willing to leave.
To assume that the company simply doesn't care about its developers walking out is a little bit of an overstatement. Many won't like a change (regardless of what it is), and if you're going to leave, you might as well leave when you perceive a negative change in your job.
Bye!
Not sure how many employees Cisco has left (didn't RTFA), but a quick glance at Wikipedia indicates that they still probably have more than 50K employees. Of course not all of them are engineers, but I have worked in organizations of that size before. If my experience is common (and I believe it is), they have already gone well pas the point you indicate. Even if they only have 5,000 engineers, it is practically impossible to hire anywhere near that many good people. You are stuffed to the rafters with dead wood. Not only that, but quite a lot of that dead wood will have made it up to management level -- the engineering and political skill sets are orthogonal, and people who are good at politics get promoted.
This means that the management probably has absolutely no idea how to separate the good engineers from the bad. In other words, just by growing the company to the size that they have, they are in a position where they can't evaluate talent. A 30-50% turnover rate is another way of saying 2-3 year attrition rate. I agree with the manager. This is common in large companies. Because they are unable to distinguish good from bad, they simply cycle through the available talent in a random fashion. They have chosen to go with quantity over quality and his statement makes absolute sense.
I don't think it is possible to do (for a variety of political reasons), but lets pretend that a company of 5000 engineers could cut back to their top 10% of talant. You'd end up with a solid core of 500 good engineers. Then, let's pretend that you knew how to do whatever it took to keep that talent for 10 year. Would the company be better off? I'm not so sure. I work in a former start up that is trying to scale itself up now. Since I'm fairly senior (possibly indicating I'm better at politics than engineering??? ;-) ) I'm exposed to more of the business end of the company. The CEO is demanding that we double our development group. He knows that this will throw the group into chaos, but he also sees a way to grow the revenue of the company by an order of magnitude if we can do some very specific work. Crucially, it doesn't really matter how badly we do it. It just needs to mostly work.
Which is better? Grow your revenue by an order of magnitude today and destroy your development team, or carefully grow your development team and trust that opportunities will show up when the team is able to handle them? It's a very difficult call. Personally, I can't fault companies who expand quickly (like Cisco did) and who take the opportunities that were presented. That's what the business guys are paid to do.
Luckily, the company I work for is wholly owned by the CEO and he has decided (for now anyway) to adopt a more sustainable growth for the company. Again, I am very lucky that our CEO views our team as being the engine of the company and values long term viability. He doesn't have investors trying to take their money out and has the ability to make the choice that leads to a very good place for me to work. Not every company has that luxury.
...the very essence of an enterprise (any enterprise) is that it is a bundle of labour and capital whose essential structure and identity is independent of and more persistent than the labour it employs. The identity behind its labour component is no more important than the identity of its capital component...
Mr. Patel was misquoted in the header, FTA he did not explicitly say "Turnover in Engineering No Problem", but let's assume he did say so in so many words. He is about 33% correct, all engineers are replaceable, and that is the main reason good engineers always document their work. But the question that is often ignored by business school 101-types is how much money and time does it take to replace a competent engineer? Can your enterprise afford the Project disruption and late time-to-market? Will your development still be relevant by the time it finally launches?
You argue that "capital" and "labor" are essentially equal to the identity of an enterprise. In a lot of enterprises that may be true, where either the labor is totally unskilled (light-bulb turners) and requires no training, or the labor is "certified and trained" and perform a set of narrowly-defined tasks, e.g. truck drivers, shipping, railroad engineers, airline pilots, etc. In product development, this ideal model breaks down. Engineering has no standardised training, and every situation or development situation is a unique learning experience, both for the enterprise and for the labor. That's why we have "project management" and development in the first place. History is full of examples of enterprises that made the mistake of treating their engineers as fungible, interchangeable assets. Products started coming out "a day late and a dollar short". Eventually they reorganised, split, made a splash with some big announcements and then disappeared.
That's what is being taught in business school. Actually, it's a few things. "It's bad to have your company depending on a single person", which is true. "Standardizing jobs / positions makes it easier to shift people around, making you less dependent on any one of them, and makes recruitment and organizing the work easier if you do this in line with the rest of your industry", which is also true to a degree. Never mind the many negative effects of standardizing jobs; the message to take away from this is not that people are drop in replaceable parts. If you did all this correctly, it'll be easier to replace a leaver, but it doesn't mean that replacing one person doesn't come at a high cost, and doesn't mean that adding or replacing many people at once is still extremely hard to do without messing up the works.
Sadly I see my share of managers who do get the idea that people can be swapped in and out at no cost. Needless to say their teams are not the high performers.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
My company is "partnered" with Cisco to develop networking equipment for smart infrastructure. Working with them is impossible, and they are completely dysfunctional as an organization. The result is that their product is total shit and doesn't work, and their attitude is that it's our job to make our product work with it, despite the fact that their stuff does not comply with published networking standards.
They've been riding on their brand's coat tails for far too long... Hopefully a Ubiquiti or someone like them will step up and fill the hole that Cisco is digging itself into.
Agreed. A manager who says that turnover is not a problem is a manager that has no inkling of what engineers do, what exactly their company produces, or how badly they are in trouble when knowledge and experience walk out the door. Either that, or they're lying to your face.
There's that tipping point when the work gets harder, the code is even more rotted, the "process" is even more constricting, because they know something is wrong but they need to "measure" everything to figure out why. That's when people are running, not walking out the door.
Oh god, the "metrics" thing. They did that at my last job, to the point it got ridiculous because you spent more time trying to update the 10 different 'tracking systems' than you did doing actual work. It even got to the point where to take a vacation day you had to update the group sharepoint calendar, plus two other systems, plus send email on it to 3 different people (any one of which could reject the request for whatever reason). It got to the point where I was *glad* when they laid me off because the technical part of the job (the 'interesting' part) was disappearing into a realm of spending 50%+ of your time updating the various systems for keeping track of the 'metrics' on what you were really supposed to be doing (or what I thought I should be doing - actual work not 'make work').
They announced several thousand job cuts at the same time that every job board today lists hundreds and hundreds of 'openings' but when you apply for them you get a response that the job doesn't exist. And tomorrow is the same thing, and so on. Cisco is a half-tarded company like all the rest that doesn't know from one minute to the next what it's doing and none of the stove pipe orgs know what the other stove pipes are up to. Long story short they're going to appease institutional investors by massively cutting the US workforce and moving it to Asia. Quality will suffer and no one will care. Any day now Cisco will turn into IBM which is little more than an investment fund that buys and sells other companies.
Cisco was an innovative company that created huge market value. Now they're becoming "lean, agile" company with no real vision or future. They want to be "market focused" yet they're supposed to push the market to their view of technology and to create markets. When you lead from behind you certainly take on less risk but you sure don't create the profit margins and patent portfolio investors look for. Sell your shares now.
Harrison's Postulate - "For every action there is an equal and opposite criticism"
Well, I was one of the (older) American engineers let go in this most recent layoff (of more to come, I am afraid). The development group I was a part of had multiple layoffs (older white engineers) and the future product we were developing has been transferred to India for further development. I don't think this will be the last time this is done ...
Cisco is transforming it's development organizations from a product centric BU approach, with combined marketing/software/hardware development, to a more centralized approach. Hardware engineers, instead of being associated with a particular product line, will now be viewed as part of a central resource pool, a commodity. They will come and go on a product as necessary.
This may be more 'efficient' from a financial corporate bean-counting point of view, but what it does is cause all the product specific history and knowledge to be lost, as there is little engineering continuity.
What it really means is current Cisco management has no idea on how to engineer products; they are not engineers, but are instead bean-counters. Cisco has begun its transformation all right, but I believe it is more to launch itself on a death spiral, much like DEC did in the early 90s when its management lost touch with its engineering roots and became marketing and finance driven.