Hacker News new | past | comments | ask | show | jobs | submit login

> "What did you deliver this week? This month? This quarter?", should be the only relevant question in the workplace, managers included.

Unfortunately, there's another camp that (with credible arguments) claims that task-estimates are almost always meaningless. If you buy into that camp, and if someone under-delivers, it doesn't tell you anything about whether or not they are performing poorly. They could simply be the victim of an overly optimistic task-estimate. As a manager, what are you going to do then?

This is pretty much the double-edged-sword in the NoEstimates movement. Either you judge people purely on the basis of results, and end up punishing people who are victims of poor task estimates. Or you don't judge people at all, and watch as people take advantage of the situation to slack off as much as they want. Or you judge them on the basis of hours-spent-at-work, which will then induce the same complaints we see in this thread.




>>Unfortunately, there's another camp that (with credible arguments) claims that task-estimates are almost always meaningless.

This is largely because people cook up all kind of bull-crap work just to keep busy and have it look like the equivalent of 'moon-landing' just happened.

Over years I have seen this phenomenon play out in every major company. The absolute worst I have seen is a whole team of 10-20 members dedicated to build that would be the equivalent of cron + ftp, implemented in super verbose java written and rewritten to make class hierarchies as complicated as possible to make it look big, and then have it projected as the biggest project ever. The team went to bag a lot of bonuses and promotions. Stuff like this is why goal based evaluation don't work.

Also look at: http://strikemag.org/bullshit-jobs/


Also look at: http://strikemag.org/bullshit-jobs .

The entirety of his argument has one data point: he has a friend who is a lawyer who thinks his job is useless for society.


What if you judge a team based on the revenue it brought in vs the cost of the employees in the team? Since profit is the real measure of success, it makes sense to use that as the metric. Measuring individual contributions is problematic, no matter the system you use. Measuring based on the entire team is much easier.


You would notice that the IT and security teams brought in zero revenue and fire them all.


I wonder if it would be more economically efficient for security teams to turn into insurance companies. So companies selling books over the internet would fire their security teams and instead buy a insurance policy against any intrusions, have the security company scour their systems for vulnerabilities during underwriting, and then pay a monthly fee and upkeep while the security company is held liable for any security intrusions.

The book company could then buy a standard product as a simple cost, while the security company attaches direct revenue to effective security.

I guess the IT/security company would need to run your infrastructure to be able to set up monitoring and such?


Ha! In fact all you would need is a sales team!


Then next quarter you fire them too!


It's difficult to judge teams based on revenue. A software company makes $100million. Is it the developers? the sales team, the marketing team or QA team that get's the credit? do you split it evenly? do you split it by the number of hours worked? If you have a company, there is really only one team, all of the company, all the other teams are usually sub teams that are interdependent on each other.


> What if you judge a team based on the revenue it brought in vs the cost of the employees in the team?

That can still be hard to accurately measure. You can measure, of course, how much revenue was attributed to sales of the product developed by the team, but how much of that is attributable to the team's work and how much is attributable to company-wide marketing and how much is due to company image developed by public experience with products developed by other teams is...not always readily obvious. (And, of course, then you have teams that aren't devoted to particular products or which provide company-wide services supporting product teams, but not directly generating revenue -- unless, of course, you organize your company so that accounting, HR, marketing, etc., are all broken up and product-team specific.)

Of course, if you measure by the entire company a lot of that uncertainty gets washed out.


So how do you judge the revenue brought in by internal facing teams? IT teams? QA? Basically, anything that isn't a revenue center, or is a cost center?


Some projects aren't directly profitable, but are important and must be done. Infosec for example. Using this metric, important jobs may not get done.


That won't work for all jobs - I work in the actuarial department for a (very) large insurance company. We can't directly affect profit. You could argue for whether or not our projections are correct, but they can be affected by many things out of our control.

I'm guessing that's true for a lot of areas in a large company. What about the department that takes care of buildings or HR for example?


Let me resolve the confusion with a simple question: when your company is contracted by another company, do they also require you to write down the amount of hours you and your colleagues worked?




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

Search: