Why big companies fail to keep talent
forbes.com
forbes.com
You probably don't know me, but you are someone whose name I recognize, and whose comments I've enjoyed over the past 2 or so years. Very sorry to see this happen to you, and for no apparent reason that I can tell. Maybe you'll get reinstated, or maybe you'll leave for greener pastures -- but either way thanks for trying to make this place a little better.
> for no apparent reason
When i downvoted several PG supporters and upvoted several opponents - zedshaw and the likes - in the yesterday's "Trolls" thread it seems it was the last drop :)
http://news.ycombinator.com/item?id=3350300
Someone just sent me an email pointing out your account had been banned, presumably by mistake, and I just unbanned it. Sorry about that.
edit: it appears it's only because showdead doesn't work for hellbanned accounts. nice. (for reference: http://news.ycombinator.com/threads?id=lookhard)
If you stay at a company, they will give you some fixed pay increase, perhaps tied to your annual review. After a few years, your pay could get seriously out of whack with the market.
Many companies have a policy of only fixing such problems after the employee gets an external offer. Of course, by the time the employee gets the external offer, they are pissed at their current employer about being underpaid, so they leave.
tl;dr; pay your employees market rates, or plan for turnover of employees experienced in your own practices.
This. In my experience, especially applies to H1-B employees or any employees who are perceived to be unlikely to leave. One downside is that, lowering the average salary of all employees makes hiring new employees (at current market rates) difficult. Thus begins (or continues) the downward spiral.
Currently, I'm interviewing new hires who will be roughly a paygrade below me. They will start with a 10% higher salary than my current.
Needless to say, I'm not a happy bunny. Sadly, there aren't that many software companies here, so I can't easily move jobs.
I guess what I'm asking is where is the line between being that guy who's always fighting management and being a yes-man? And are all of these things really actionable issues?
I used to get really unhappy about being asked to just "get a quick fix" out the door. At my next job, I wasn't nearly as internally angsty about this, given that there is a tradeoff between what the business needs ("this bug needs to be fixed now so that merchandise can arrive by Christmas") and core engineering.
I often wonder, then, if my previous position would have been less stressful to me had I a different expectation about the tradeoff between engineering-vs-business needs. To me, working with smart people was something I wouldn't compromise on. But doing non-interesting bugfixes? Less of an issue than it was previously.
Living with stuff is needed I think as long as you have some sort of hope, once the hope is gone person checks out and will leave or turn into dead weight himself.
First is the issue of bureaucracy. This doesn't matter to me; it's hard to get individuals to do things, and it's hard to get big corporations to do things. If you want something done, do it yourself. Remember, the same bureaucracy that won't upgrade your Linux kernel is the same one that would be in charge of punishing you for doing it yourself. So don't fear the consequences of actions; if something feels right, just do it. (The one procedure that we can get our sysadmins to do here is to reboot a machine. So we have a "firewall rules" script, writable by developers, that is run from rc.local. If we really need some package installed, we do it from that script and then request a reboot. Against "change control policy"? Probably. Do I care? No.)
Next is having good projects. I suppose this matters for some people, but at the end of the day, I find pretty much everything programming-related interesting. If someone wants me to manually edit a billion records, or something, that's simply not going to happen, so nobody asks. You can't be afraid to push back if someone wants you to do something that you'll hate doing. Nobody wants you to hate your job, after all.
Performance reviews are always stupid. I've never seen the point of them. The people doing the reviews don't know how to program and don't take input from programmers, so the review boil down to random guessing. Which is fine, because a good review gets you no raise, and a bad review gets you no raise. It's just a big waste of time. (I get "meets expectations" every year, because they can only give out one "exceeds expectations". I mostly find it hilarious because I'm consistently in the top of the list of edits to our company-wide source repository. If being the top 10 in a 75,000 person organization is "meeting expectations", the expectations are a little high, I'd say. But that's OK, because management doesn't even know what edits or source control is.)
Strategic priorities are amusing. A bunch of people that know nothing about business or software will make lists of important-sounding things. The reason you are considered "top talent" is because you know this is bullshit. Ignore the todo list and work on what you think is important. (Same goes for the next point, being told how to do your job. If your management can't do the job, how can they check that you are doing it their way? They can't. So do things right.)
"Top talent likes top talent." That I can agree with. I know people can't be fired from big companies, but I wish they could be indefinitely suspended with pay. ("We'll pay you to STOP CHECKING IN CODE.") Then the three people with a clue wouldn't have to waste their time reverting the mistakes of the people trying hard for a good performance review.
The next three things boil down to how management works at big companies. If you are a really amazing programmer, they're not going to make you a manager. That's because they need programmers, not managers. So managers end up being blown-up programmers with enough people skills to get promoted. That means they make decisions with people skills rather than with programming skills. In order to get buy in, you have to "play the game", that is: don't treat it like your glibc mailing list, treat it like you're trying to get someone to date you. Be nice, say how your idea will unify teams, etc. People that can't understand details don't want them. Play to their people skills side, and everything will work our for the best. "I heard about this project and implemented it over the weekend" also works.
Anyway, I think the biggest problem is work environment and pay. I can get a 50% raise if I quit and go somewhere else. I can get a 2.5% raise and 20% bonus if I stay. The economics tell me to leave. You can't beat the economy. Same goes for work environment. I don't really believe that a top 5 corporation can't afford a 30" monitor for me. Stop lying and buy me the shit I need to get my job done. (The reason they don't want to buy people expensive equipment is because most people don't do any work. If those people see the three good programmers with bigger monitors, they'll want them too, just to feel good about their dick size. This goes back to the problem of not being able to do performance reviews properly.)
You really should consider going elsewhere: I can show you places within a five mile radius of Downtown Mountain View (or SOMA, or The Mission in San Francisco, if you don't like suburbs) that not only do all that (that is the bare minimum) but also, e.g., write production code in Haskell (or whatever else that you're interested in).
But the reality is: you can let your soul be crushed by evil, or you can like the likeable parts of your job and ignore the parts you don't like. It is sometimes fun to be smarter than everyone else, after all.
2) I'd hate New York also, but you're not moving there for the rest of your life. I know people who've moved from Mountain View or San Francisco offices to Seattle offices, and vice-versa while staying at Google. The Cambridge Office is quite nice as well.
I personally don't like Bay Area at all (San Francisco is disgusting, rest of Bay Area feels like you're stuck in a bad 70s movie), but there are only a few metropolitan area where software engineers are appreciated.
3) Just do it: I saw your comments on this site, I saw your Github repositories. You'll find actual culture fit at Google, something you won't be able to appreciate until you actually have it (or, on the flip side, as I found out myself -- until you've lost it and found it again).
Just don't use working at Google as an excuse to stop working on personal projects.
I don't really care if working for Google increases my market value, since I'm not sure I would want to leave Google once there. So it makes sense to me to get salary sorted out now, and then move to Google. If I passed the interview once I can probably do it again.
The reality is, if I didn't have to move, I would have accepted Google's offer instantly. But New York is expensive, and moving is a huge pain, and so the value isn't there to make me think, "yes, I must do this". I don't want to coordinate movers and look for apartments; I want to ride my bike and write software.
(Something that was strange about the Google negotiation process was that they only tried to match Amazon's Seattle offer; they never asked me what I wanted in order to move to New York. Take it or leave it, not negotiable. So if I can get what Google offered me from my current employer, it works out better for me in the short term.)
Edit: as it turns out, my current employer "can't" match my offer at Google. So, I'm moving to New York :)
You hit the nail right on the head. I used to say this all the time when I was working for Oracle. There were plenty of people who weren't even contributing nothing - they were forcing the competent people to take time away from real work to fix the bugs these people caused. Negative value, indeed.
(But the rules are changing. Right now, I only have to click one button to deploy to production, and it requires no manager sign-off. We hired a new CTO and that was the result :)
We have "phase reviews" before anything is released, no matter how minor. A "phase review" is essentially a long meeting with a dozen or more people (including one or more people from development) where the PQMS people bicker about the wording of something but no one cares that the thing does not work well. Then half a dozen people have to sign the documentation.
At the end of each sprint (we do something that we call Agile but is actually its antithesis) developers have to sign off on their peer reviews, which have been printed out. QA people have to create several documents (this seems to be QA's main function) and sign them and then everything is signed by multiple managers who know very little about what went on. We also have daily "stand-up" meetings that all development and QA people must attend. These meetings usually last 15-30 minutes but can last an hour or more. Before each sprint we have a "design review" meeting where people who know nothing about software development try to create user stories in our ticket system while everyone watches. A few days later we have a retrospective meeting and then we do sprint planning where we watch the same people who created the user stories try to enter sub-tasks for developers. Most of these meetings must be documented and of course people must sign the documents.
There is also a large repository of documents which supposedly describe every process that we use. These documents are of course inaccurate and rarely useful. A few of them are updated each week and everyone is required to read the updates.
No one, other than top executives who do not care, has any real power to dispute any new policies that PQMS creates. I should also mention that the people in the PQMS group have no understanding of software development.
An interesting side effect was that the group I was in made a point to use the best software engineering practices they knew (100% test coverage, all tests pass with each checkin, every checkin was code reviewed) because the engineers knew that, once code went out the door, it could be a long damned time before anyone touched it again.
With regards to having interesting projects, I'd add that if you're in a big company, then in all likelihood there are tons of projects you will find interesting if you look hard enough (and if you're a tinkerer like a lot of you are here, this shouldn't be all that difficult). If you can honestly say you've rotated, shopped around, interviewed dozens of managers, and found nothing that can balance your compensation needs and your passions, then get out of dodge, stat. Otherwise, as my dad used to tell me, stick around until you run out of interesting/fun things to do.
Perhaps one of the expectations is not putting fucked up shit like package installs into init scripts.
That's a wonderful idea. It sounds like you're at a much more open "big company" than I am. You see, I don't even have the access to install stuff on a production box. I have to give it to an infrastructure team to install for me. And they aren't going to do anything without me going through a process that takes days of approvals and no less than 5 different documents. It doesn't matter how small the change is. If it needs to move fast, you need even more approvals, but the built-in rules of it taking so long are removed. Still need all of those documents though or they won't install it.
Most people in my ISD don't even have the ability to download. They don't have admin rights on their box. Most people are using 17" monitors. I was only too happy to get a 19". It was only a few years ago that they finally decided it was ok to give us internet access. Freaking internet access! This is my big corporate world experience.
I recently gave an estimate to someone which would take me 2 hours to do, and 4 to go through the change control process etc....
Of course that cant be taken at face value since im not allowed to estimate. My estimate is taken by a designer who produces several documents. They then budget for the following, designer, development lead, design lead, business analyst, tester, product owner, business tester.
I checked what my 2 hours work 4 hours testing etc... and its now an 80 hour effort. With 10 hours spent already producing the documentation and at least 3 levels of management discussing it.
For the record I implemented the change while giving the estimates and it ended up taking me an hour, but is still sitting in development.
Don't even get me started on how much time (weeks) effort (4 levels of management, weeks of meetings and at least 10 people involved) it took to get an additional 2 gig of RAM added to a production server which only had 2 gig to start with. I think the cost in man hours would have been at least $50,000 for a stick of ram which actually cost nothing as its already in the server and just needed to be enabled.
Oh on the Screen thing. I bought my own. 27" monitors can be had for $300 or less these days. Easier then trying to justify why a 24" would be advantageous to me and why dual 19" isn't as good.
1. Failure to offer competitive pay. 2. Failure to provide a great work environment
Companies that look at their employees as "resources" (read: commodities) will not see the value in competitive pay, a good work environment, or anything else on the article's list. It all stems from a fundamental misunderstanding of the role of talent in an organization.
Something tech companies have grokked for awhile, which a lot of other industries really haven't, is that human resources is a strategic discipline when it's done correctly. Good HR strategy recognizes that employees/talent are the lifeblood of the company, and that the loss of great ones is as potentially catastrophic as the loss of millions of dollars. When an employee who's capable of generating millions of dollars' worth of innovation, technology, productivity, insight, and opportunity to a firm leaves the firm, the total opportunity cost of his or her departure is precisely those millions of dollars.
More employers should endeavor to understand that equation.
I'm at a "Big Company" now and the only reason from the list that pushes me away from here is #1. We spend so much time attending meetings to deal with the overhead of bringing in different dept. personnel to the projects that its boggling. There is an amazing amount of work up front on any project to ensure we meet standards of the company and other rigorous rules that don't exist in smaller startups.
Much of it is necessary too. I work for a rather small ISP but a big company for my area. We manage thousands of devices and connections that need to follow a common standard or else the network management is impossible. Almost an entire week of meetings were used to work with different support groups in the company to ensure the new monitoring software was capable of being configured in ways that they needed it to be. In a small group you could probably yell over the wall at the person who cared and get the answer you needed but with us we have 8 different departments with different vested interest in the outcome so we need to please everyone while still keeping the budget down and management pleased with the timeframes.
There's other issues working here too but those aren't unique to a large company so they don't necessarily belong on a list like that.
And before someone from my workplace reads this and freaks out I guess I should mention that despite all the bureaucracy we deal with I still very much like my job. I wouldn't have turned down other offers to come here if I didn't like it and I wouldn't have worked my ass up the food chain within my first year if I didn't want to get more involved with it.
Well, no, not really. This strikes me as patronizing, as if they're saying, "those silly employees say they mean X, but they really mean Y." Well, no, I mean X. When I say I don't like bureaucracy, it's not because I can't get along with rules I didn't have a hand in. I can deal with other people's rules. Big companies have certain disadvantages in communication and coordination, and things like rules and processes and standards can help. I totally get that.
But what I keep seeing is that nobody's looking at what the rules are trying to accomplish and trying to make it easier to follow them. You want every change to be accompanied by a requirement or bug reference? Great--not a bad idea; make it dead simple to do. I remember filling out paper forms for code review documentation as recently as a few years ago. That's just silly. Code reviews aren't bad, but paper forms?
There's hundreds of little friction points that add up, though. The ubiquitous second/large monitor. Stock machines with slow, small drives and RAM. More and more network resources moved offsite, accessed via a slowish WAN. Limits on email storage, and auto-deletion. Limitations on what software you can install. It goes on and on, down to the breakroom amenities, office supplies, and so on.
Every little (needless) obstacle between me and the work getting done just pushes me closer to the door. Any difficult work is going to have obstacles, sure. But why make more?
Unless you're in quite a large amount of control of a company's direction, it's likely after enough time (if you're talented) you'll want to move on to working on something that is outside the scope of that company's focus.
Following the Adams logic of the opportunity costs, all these "stupid boss, performance review, process" reasons are there to help you to not get comfortable, to help you by providing a motivational nudge to make a move.
"bigco isn't willing to pay for [superstars] -- they are executing an established business model quite effectively without superstars, and it makes sense to continue to do that while its economically feasible."[0]
[0] http://www.dustingetz.com/the-unnecessity-of-superstar-middl...
So why not go to a smaller company where people listen to your ideas and you're able to do what you love and make a difference? I think the thing people want the most is to know that they're making a difference. This is nearly impossible at a large company.
The article fails to support the theory that big companies are any worse at retaining top talent than companies in general. Not surprisingly, people who are highly talented tend to be in more demand, they tend to get more offers, and they tend to have more mobility between jobs. When they want to move (for whatever reason - personal, boredom, etc) - they can.
There are a number of good tech companies that recognize this and make sure that if a valued employee is leaving, they leave on good terms and it's made clear they can come back later if they want to. That makes a lot more sense than trying to figure out how to prevent talented people from ever leaving.
Whether it’s a high-profile tech company like
Yahoo!, or a more established conglomerate like
GE or Home Depot, large companies have a hard time
keeping their best and brightest in house. Recently,
GigaOM discussed the troubles at Yahoo! with a flat stock
price, vested options for some of their best people, and
the apparent free flow of VC dollars luring away some of
their best people to do the start-up thing again.
Places such as DuPont have a lot of long term scientists. They offer the best unprecedented freedom as well as a lot of facilities and support. In startups, a worker has to wear many hats, and not all wish to do that.
Most of these issues can be traced to a single cause, which is that as companies grow, there's a growing 'diffusion of responsibility' effect that takes place in terms of people's responsibilities towards one-another. Bosses and managers are clustered and have an ever-changing set of direct reports, ergo they see the responsibility of engaging and keeping talented people as a 'company' problem and not their problem. Similarly, talented people see the company as an uncaring monolith, and not a set of individuals that can help them get to where they want to be.
In the end, there is no 'company', there are only the individuals that compose that company. Their decisions make things happen. The less agency you give those individuals (or perceive those individuals to have), the harder it's going to be to keep the most talented around.
There are my initial reactions to all the points.
1) Bureaucracy getting you down? Tear down/bypass useless red tape.
2) Can't find an interesting project? I'm sure there are hundreds of interesting teams nation/worldwide you haven't met yet.
3) Poor annual performance reviews? Learn the system and work it, even if you have to play kiss up every now and then to important people. It's your money in your bank, after all.
4) No discussion around career development? No lead is going to turn you away if you go into his or her office and ask for it.
5) Feeling jerked around? Stand your ground and don't be a yes-man (or woman).
6) No one holding you accountable? Call for your own brainstorming sessions and peer reviews.
7) Can't find smart people? See note above about finding an interesting project.
8) Don't understand your company's vision? Either take ownership and try to influence it if it's that important to you, or keep your head down and keep doing awesome work.
9) Encountering closed-minded imbeciles? See note above about getting jerked around.
10) Don't like your boss? See note above about finding an interesting project.
The reason why I generally dislike working at my big company (wonder if they'll see this!) simply boils down to a lack of challenge. Not intending to come off as arrogant, but if I can dedicate 20% of my brainpower and consistently get rave reviews from everyone around me, something is seriously wrong with the picture. So I generally wait until the last minute, code sprint, say "check please," and go home and do something more interesting with my life.
I was pretty much forced to quit 2 weeks later. Of course there were some other issues, but the point being, some people don't really like you standing your ground and would rather you be a yes-man.
The article is about employees who leave companies. Such people are not lazy, complacent, or comfortable; quite the opposite. They don't like wasting their time playing the games you describe in order to do their jobs. If they have the opportunity to leave for greener pastures, they will. More power to them.
Middle managers are like giant herbivores who multiply like crazy. You need to cull them once in a while or they will eat the whole place.