Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> This type of innovation takes significant up-front design time, and working on components over longer than one week iterations. Because the projects have such simple external interfaces, and so much internal complexity, much of the work is not even visible to “customers”, so there is no way to write customer visible stories about it. This type of software takes 8–20 months to deliver the first working version to the customer.

At Yahoo, I designed and built a large project. This took about six months to deliver. At the time, the company was doing quarterly reviews that I think Marissa had imported from Google. Anyway, my manager had rated me as "meets expectations" for a few quarters because this project and the one I had previously worked on weren't visible to "customers" till they were delivered, so he didn't have any evidence to justify a higher rating against other managers' team members.

Little did my manager know that a few quarters of "meets expectations" had caused HR to drop me into the bottom 5% of the company and so I received a letter from HR that I was at risk of being terminated.

So I deliver the project and now it's visible and everyone loves it and I get an "exceeds expectations" rating and then a promotion and a raise.

From being warned I'd be terminated to a promotion in less than six months, with no change in my work, but simply it becoming visible. Whee big company fun.



> Little did my manager know that a few quarters of "meets expectations" had caused HR to drop me into the bottom 5% of the company and so I received a letter from HR that I was at risk of being terminated.

This is disturbing and, I think, a twisted form of grade inflation, mixed with the usual suitspeak where words don't necessarily mean what they mean. If an employee is as good as you think they should be, why would you put it at risk of termination?

For the record, I also work in a big company with long product cycles, meaning that the product I'm working on started more than one year ago, and the first public release is planned for next December, so I feel your pain. Luckily our process is a bit more sane and our manager follows our work closely, so I'm getting good ratings (but I wonder if the grade inflation will continue in such a way that "exceeds expectations" now means "subpar employee"...).


This is 100% caused by stack ranking, and the problem you identify is a very real one. Chopping off the bottom 5% of employees works if you have a LOT of dead weight, but realistically you can't really do it continuously or you start removing legitimate talent and, just as worse, fostering a toxic community that values playing politics over delivering value.


Not only that, but chopping off the bottom 5% typically makes room for more hiring; these emptied jobs are likely to be filled with less-than-stellar candidates. It take the new hires a few years before they too are dropped down into that lower 5% rank.

Stack ranking ensures that you have churn in your workforce, and not in a good way. You wonder why workers in the tech industry move around so much? Look at stack ranking as a significant contributing factor.


That’s by design. Keeps the workforce young and insurance cheap.


Less cynically, it also increases the odds of finding good employees. A "bottom 5%" worker is statistically less likely to suddenly rise to the top of the pack than a new hire is to produce at that level initially. And, more cynically, that remains true even if there's significant measurement error in identifying that 5%.


That's true if the performance ratings are cost-free and fairly accurate. A company where firing is based on misconduct and promotion is based on achievement, rather than basing both on quarterly reviews, might actually have a better chance of finding good employees, and perhaps more importantly, retaining them.


Why would companies prefer cheap insurance over productivity? If they want to pay less, they can just pay less. People would rather get paid less than get fired.


Productivity is hard to measure. Insurance cost is easy to measure.


Is it about cost?

It’s often easier to get that pay raise by hopping companies. You’re then replaced with a new hire who is probably getting more than you did. And needs a few months to get up to speed.

Treating your proven employees well to retain them would cost less.


Big companies are driven by the mean and dollars. The short term numbers work out, and long term productivity issues are addressed by acquisition.


I worked for a large global company and this matched exactly what I was seeing. I had projects with year or more development cycles before something was deliverable so "meets expectations" was difficult when you had nothing to show for your work as they only cares about final results. We even had an unwritten rule where everyone must have at a minimum two "needs improvement" because "everyone should be working on making themselves better." This lead to a dark rabbit hole and a lot of engineers leaving.

With such a messed up evaluation process engineering demanded direct, documented process for doing evaluations. Instead we had managers trying to gauge output based on defects fixed and lines of code committed. You could tell management had no clue.


This lead to a dark rabbit hole and a lot of engineers leaving.

But, I bet, a large and well-resourced HR department, which was the real goal. Who invented the system, after all.


Don't call it 'suitspeak' -- these suckers haven't ever had the decency to wear formal business wear; it's `golf shirt speak` at best


A previous employer had had that rampant feedback inflation for years, and reset it one year. The Big Boss - quite reasonably in my mind - said “our expectations are high and you should feel proud of meeting them”. But the company culture was still set up around “strong exceeds” being the norm and “meets expectations” being code for “massively underperforming” so that was an uphill battle. And many of those who had gotten used to “strong exceeds” really were massive underperformers. Really to make this work they should have deleted the entire history from the HR database.


If an employee is as good as you think they should be, why would you put it at risk of termination?

Because quality of the employee and the employee's work are not the only factors in hiring and firing decisions. Sometimes a smaller workforce is what makes sense, and if all your engineers are "meeting expectations", what are you going to do?


There are other factors but just one is under discussion: cutting the bottom five percent in performance reviews. And if consecutively "meeting expectations" puts you near the bottom, then the expectation must actually be to exceed expectations.

Nevermind that this policy necessarily means churn and undervaluing aspects of software like security or fault tolerance and a constant drain of institutional knowledge.


I'm not arguing for the policy. I wouldn't want to work at a place like that.

But I feel like this isn't very hard to understand and I don't know what you're not getting about it.

And if consecutively "meeting expectations" puts you near the bottom, then the expectation must actually be to exceed expectations.

Uh.. no.. you seem to think "meets expectations" necessarily means "will not get fired". This policy exists, as dumb as it may be. Imagine you're a manager at a company like this and you're tasked with giving a performance review. You have two choices: you could do what you seem to be implying they should go and fudge the ratings, so that the bottom 5% always get "does not meet expectations." Or you could say "fuck that stupid rule, I'm going to rate this person honestly, and if they still fire him that's their choice."

A performance rating and a company policy about firing are two completely separate things. I think you must have a naive understanding of how staffing decisions are made in the real world.


Eh, the language makes a bit more sense than that. It's a bit too euphemistic for my taste, but it's reasonable.

"Meets expectations" — which expectations? The expectations for the role of for the employee? If we're talking about the expectations for the employee, then obviously it makes no sense for meeting expectations to be a bad thing. But if instead we're talking about expectations for the role, it's perfectly consistent to say that an employee who perpetually merely meets the expectations for their role is subpar, if employees are expected to continually improve.

Now what's less clear is why companies care about the derivative of their employee productivity in a labor market where employees stay with a company for just a few years.


A bus driver that “meets expectations” is the perfect bus driver, I don’t want him to “continually improve” thinking that he’s the new Ayrton Senna, I don’t want to be driven around by drivers who think that they’re Formula 1 drivers. How are programmers different from bus drivers?


> A bus driver that “meets expectations” is the perfect bus driver

By what standards are Bus Drivers evaluated? Near accidents are OK as long as they're lucky enough to not be involved in a real accident? If so, I'd prefer they actually improve and decrease their odds of being in a future accident. Does efficiency matter? Maybe one that's on time more often is actually better? Maybe customer service matters, and they can get better at helping people who need to buy tickets for the first time?

> I don’t want to be driven around by drivers who think that they’re Formula 1 drivers

It seems like there are multiple dimensions that a bus driver can improve on that aren't "become a race car driver". Given that, it seems like the bus driver analogy already isn't a good one.

> How are programmers different from bus drivers?

It doesn't even seem like we need to answer this one. You started with the false assumption that there are no dimensions that a bus driver can improve on other than becoming a race car driver. One could argue that there are much wider ranges of value creation in programming between average and above average programmers, but that's irrelevant given your initial premise is obviously flawed.


No, I think this is a fine metaphor. If an engineer can understand a problem, identify a solution, and then implement, document, deploy, and support it in production for project after project, it’s completely legit to say they’re good engineers, and are not necessarily improving in any relevant way.

Similarly, a bus driver that consistent drives without causing accidents, doesn’t spill the passengers’ coffee, doesn’t burn too much gas or wear out the breaks too quickly is a good driver.

What you say to either of these people is “Great job, we love you, keep doing what you’re doing!”

Encouraging growth and improvement as an end in itself can be destructive: How many projects amount to rewriting something that works in some new language or framework because an engineer wants to pad their resume or just learn something new?

Craig Mod recently wrote Fast Software, the Best Software; I’m hoping he follows that up with Software That Already Exists and Works Fine Using an Unsexy Suite of Technologies, Software that Doesn’t Need to Be Rewritten.


> No, I think this is a fine metaphor. If an engineer can understand a problem, identify a solution, and then implement, document, deploy, and support it in production for project after project, it’s completely legit to say they’re good engineers, and are not necessarily improving in any relevant way.

We agree. If someone has maxed out all the relevant dimensions then there's no room for improvement. The problem is that there's a difference between that and average. The other problem is that there's continual room for being even better at identifying solutions.

> How many projects amount to rewriting something that works in some new language or framework because an engineer wants to pad their resume or just learn something new?

Unneeded re-writes and getting better are orthogonal concepts. That you're confusing them here underlines the logical fallacy that you're making. If there's legitimate room for improvement (and there generally is in bus driving and in software engineering), and if that improvement makes you substantially better at your job, then it's worth it. In neither of those areas is the "average" employee completely topped off in where they can grow.


>How are programmers different from bus drivers?

In that programmers are supposed to be creative, over-deliver, etc.

You'd worry if a bus driver got from A to B in half the time driving twice as fast suddenly.

But you'd be OK if a programmer you've asked to design system with features A, B, C and performance P, also delivers features D, E, F and performance 2*P without being asked!


> In that programmers are supposed to be creative, over-deliver, etc.

Like I said, I don't want the programmer in charge of the software that manages my financial or health records to be creative or over-deliver, quite the contrary. I'd add personal-data to the mix, and now I've covered a huge chunk of SV companies. I think that the era of "move fast and break things" should be over by now, unfortunately relatively paltry $5 billion fines won't stop the creativeness of some companies.


>Like I said, I don't want the programmer in charge of the software that manages my financial or health records to be creative or over-deliver, quite the contrary.

Sure, but most programmers don't program systems that manage financial or health records or write the software for the ISS.

For the majority working on enterprise backoffice stuff, CDUD, web services, mobile and desktop apps, websites, and so on, being creative and over-delivering is OK, and even encouraged.


You'd like your financial and health records to be managed by average-quality software? That is, software that's full of bugs, confuses its users into making lots of eyes, and is insecure? I'd rather have them managed by file clerks on paper if that's what's on offer on the software side.


Lots of errors, not lots of eyes. This error brought to you by my failure to successfully use well-above-average software written by Googlers.


> From being warned I'd be terminated to a promotion in less than six months, with no change in my work, but simply it becoming visible. Whee big company fun.

They probably deduced from this that their warning system worked as expected.


I think the probability of you being right is definitely above 50%.


I'd say it's somewhere between bottom 5% and top 10% ;)


Regression to the mean tells you that if you reward success and yell at under performers the successful people will get worse and the under performers will get better. Lesson learned: All yelling, all the time.


And did your manager go on to get another promotion? And may be few more team members had similar jumps in performance?

A new manager we had deliberately did this to us. Few of us got marked as "under-performer" levels at random times - risk of being terminated by the bell-curve justification and then within 6 months (not at the same time) we all were "exceeds expectations". The few of us figured out what the manager had done - after 2.5 years. By then she went from being a manager to a senior director with a decent portfolio - and that too pretty quickly. Oh why not! she created "stars" and "performers" out of under-performers.

I ended up "deliberately" underperforming for the next 1-1.5 years after they first tagged me. How hard can it be to NOT work? Well it is hard. I invested in learning lot of stuff. But management always figured out I was more than meeting expectations, got me raises and promotions. May be forwarding emails did the trick. But then I got bored, frustrated and quit.


The engineers who I have seen game these systems inspire a mix of anger, jealousy and admiration. I can never decide if those of us working hard and trying to make things better are dumb or if the people exploiting company policies are.

I watched a new hire recently lynchpin himself into a critical part of the software, make larger then life promises about new “cutting edge” tech in presentations, constantly post articles in Slack, and finally stop showing up or being online much at all other than to do some lip-service and make the occasional PR. I am a little envious of how little he does and how much praise he receives for checking all the boxes with higher ups.


Where I work this is an "Architect". I'm in the middle of a project designed by these same people to use these "new cutting edge technologies" we are essentially replacing one legacy pile of shit for another new pile of shit that is ever more so complicated to maintain. It blows my mind the money that it being wasted.


In agile, or any other project management process, the "customer" is not necessarily just the final user but any stakeholder.

As a rule of thumb: anybody who needs regular progress updates on a project is a "customer".

The difference in agile vs other development processes is progress reports are partial releases of working code instead of a percentage increase on a gantt chart.


Sorry you had to go through such obviously bad management. Just to give some context about how these guidelines are supposed to work at Google: being managed out for staying at Meets Expectations is something that's supposed to be only applicable to entry-level roles. (when I was there, this applied to the new grad T3 rank, as well as T4, I think this may have changed since I left to be just T3).

But at an entry-level rank, it is possible to get good ratings and even get promoted if your product hasn't shipped to customers yet (and I would do this with my directs routinely), as long as you are delivering milestones. Part of the definition of T3 is that you cannot yet independently work on a project, ie you need help from senior devs to get things done, and IMO if you stay at this level for more than 1.5 years (3 reviews), and there are no other extenuating circumstances, it's appropriate to consider if the company is a fit.

At more senior levels, you have to show business/customer impact to get promoted, but there is also no notion of being managed out for meeting expectations.

Of course, these guidelines aren't always implemented or communicated equally across the company, to say nothing of other companies that copy only parts of the process.


That termination threat is to me a signal that the company hates me and the business relationship is unrecoverable. I'd be polishing my CV and would be gone within a month of finding a better opportunity. Likely with a raise while I was at it.

Toxic environments like that are not worth working in. All sorts of other "interesting" corporate cultural aspects are usually also present. Their ethics are compromised so fraud and other criminal activity etc is probably going on as well. Even if not, the company is badly run and long term will fail in various ways for foolish reasons.


How is this even legal? Is there a movement to ban stacking ranking? If we don't voice our concerns as employees, then nobody will.

Also the fact that "meets expectations" is concern for firing makes absolutely no sense. A plumber who "meets expectations" in fixing my toilet is a good plumber. I don't expect a plumber to go "above and beyond" and give me a Thai massage too.

Absolutely unreal some of the crap we put up with in this industry. Blows my mind that there are actually humans out there in management positions advocating for and implementing this totalitarian dystopian garbage, throwing away their employees for "meeting expectations" as if they're disposable "widgets".


This is a sign of a sick and abusive culture. Once process becomes more important than people then the evil ones will work the system and climb the ladder hurting everyone in their path. Yuck.


Look on the bright side: Yahoo is an example suggesting that at least in tech if a company is managed badly enough this eventually results in its demise.


Huh, as much as I've heard, good luck ever getting a promotion at Google with a track record of MEs and a single EE. People with SEE regularly get their promotions denied.


That's because it's uncorrelated, not high bar. Until recently, the manager giving you EE and SEE is totally different from and actively distrusted by the promo committees.

And on top of that, the criteria are different. Working a little faster than your peers is EE, and is rewarded with raise and extra bonus, but that's different from performing in a higher level role with qualitatively different expectations.


Can confirm. I didn’t get my promotion till 2xEE and 4xSEE.


Your post is implying a few things that compel me to ask:

1) There is a pure relative ranking firing cut-off at Yahoo regardless of how well the people at the bottom do?

2) Does Yahoo make this clear when they hire you?

3) Your manager was so incompetent that he could not judge your performance outside of customer facing product?

4) A company as big as Yahoo thinks its going to survive alienating the personality that looks for big company culture with that kind of "make the cut" performance review?


Stack Ranking at yahoo is no more, at least officially as of a few years ago.


The problem, so to speak, is that companies are getting extremely data driven, and constantly need some form of metrics to evaluate their employees.

This again can turn into a culture where doing what's expected is devalued to lowest score - because you have that system where there has to be bottom and top performers.

And you sadly end up with a situation where workers are (almost) embellishing their projects to get more visibility.


My company insists each ticket in Jira have a time logged on it now. This is on top of story points. Everyone I know has pushed back on it, but I hope this isn't becoming a standard elsewhere.


Product / project / scrum guy here. Logging time won't make sense unless each ticket is one person working on it at a time. The moment it becomes teamwork (like asking someone else for their thoughts on an idea) the value of time is meaningless.

People are also useless at estimating time in advance, but pretty great with throwing a story-point number on a given story with the right guidance. Please feel free to schedule me in with your uneducated upper management. They're about to lose value.


Many companies use Jira tickets to track employee time, instead of having a separate time tracking system.

This creates a situation where everyone is searching for tickets to make up for their daily 8h.


Same in the company I work at, but only for IT employees. It's fine as long you have over 80% of the monthly hours in you contract tracked. Definitely not used for micromanagement. I myself find it useful for seeing inefficiencies in what I do and ensuring I actually go home.

It's handy for charging clients for development work specific to them.


The workplace culture this kind of Lord of the Flies management approach results in must be horrendous.


My project just delivered MVP 1 which automated a certain infrastructure build process that was previously a mix of manual, semi-manual (people running scripts by hand) and automated. In parallel to that green field development I also fixed the issues with the previous solution. Happy path for the old tool is down from 20+ days to 4 and dropping, happy path for the new tool is hours.

Now that I've delivered those improvements my boss added reworking the software stack that feeds my current system. He also said to me "Oh, BTW RIFs are coming, take that how you will."

So I'm not certain if at this point I'll be RIFd right after delivery of a complete retooling of our infrastructure build process.


So I'm not certain if at this point I'll be RIFd right after delivery of a complete retooling of our infrastructure build process.

Did you write the documentation yet? I think you know what I mean.


Seems a lot more impersonal but this is a big possibility at small companies too

A specialist working on a platform that doesn't need the whole backend team is isolated and easily skipped over for all accolades


That sounds interesting a few years ago I worked on a project (the back end system that managed large chunks of the core UK internet infrastructure ).

That had an extended 9 month design phase - but a short 12 week agile sprint phase that delivered two intermediate POC versions and then a final working project (we even delivered hardware when at the last minute the customer admitted they hadn't ordered a server) - we even took enough networking gear that we could have installed a net work if that was missing to.


Ugh. If "meets expectations" puts you in the bottom 5% this says to me that there's wild miscalibration in the review process; e.g not everyone is using the same standard for "meets" and some teams have inflation going on. At my last employer we had lot of cross-review between teams to make sure everyone applies a similar the same standard, just to avoid this problem.


So no peer (fellow engineers) reviews but solely manager?


Why would meeting expectations put people at risk of being terminated? Do they expect one to do more work than one was payed to do?


If they had fired you, you could have taken your code and created a startup.


I have never heard of a tech company that doesn’t require that you explicitly give up ownership rights to software written on the job, so good luck with that


It sounds like your manager failed to adequately represent your work.


I was at Y! at the same time , I witnesssed so many managers gaming the review system . So many funny , and some sad stories from that time.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: