Why is it so hard to measure productivity?
fractional.work
fractional.work
Do we measure trust (upon which all business is based)? If we relinquish individual productivity from our “measure all the things so we can improve them” obsession to the soft realm of the immeasurable, we might magically stop wasting so much time on stupid shit and accomplish a lot more meaningful work.
Many individuals don't like startups because of this risk, most startup only get 1-2 chances to get productivity right. Very few waste time measuring productivity.
If they don't get productivity right from the get-go, they only get 1 chance instead of the "1-2 chances".
That's the risk most individuals don't like about startups, if productivity is not a centerpiece of their operation, the leadership pushes for the only other solution they believe: long hours in inhumane working conditions.
I don't believe there's causation between a start-up productivity and their product success, but I would love to be proven wrong.
Option 2 - Measure
Option 3 - Use judgement
We undervalue qualitative measurements when talking about this stuff. But in real life it is all there is. If you did everything with a measuring tape, you could do nothing (not even walk to your car!). If you care about nothing and close your eyes, things will get disorganized and chaotic and out of control.
This doesn't mean measure nothing, but don't try to get some perfect measure of productivity. At least not in creative work like software development.
Micromanage here, red tape there, metrics-squeeze salary people and blame anything but your management tactics when things go south. I have been fortunate enough to have had some managers who knew better than all this nonsense though.
You just can't argue against results.
because the people asking the questions aren't the ones who actually do the work. And timelines are everything to those people (which admitedly falls behind a lot in software due to the nature of the work).
>Do we measure trust (upon which all business is based)?
in an ephemeral way, yes.
So no. Or why not measure productivity in an ephemeral way.
Unless you're in some stack ranked program, lack of trust is the easiest way to be first to be laid off, or on the slower track to be put on a PiP (officially or not). Sadly and ironically enough, "productivity" is one of he few ways to counteract this bias. Having a hard trail of evidence that you met every and all goals, a hard trail that these were the goals to begin with.
I could go on about how you gain trust, and indirect trust or trust via authority, but I think you get the point.
In business this means that if you have a machine that produces X widgets per hours and costs Y dollars to run, you can estimate is it worth running it at all or it's not economical to do that.
With teams of people managers/owners solve the same problem - I have a fixed amount of resources and need to allocate them properly. No measure = no good allocation = going out of business.
The reason capitalism creates more and cheaper goods that socialism is that resource allocation problem is solved by every participant in the free market (or mostly free market). Without measurement, the owners can't allocate the resources properly and they'd go out of business.
If you have worked in a team with badly performing members who don't pull their share of the load this creates imbalances in the team and the best performing members of the team leave, because they don't want to deal with the laggards.
Yes, absolutely. It's difficult to do this in customer surveys because you need a motivation for the customer to engage in a feedback process (e.g. a product review, or a questionnaire after a support call), and then the feedback is mostly about that specific event. But focus group research will absolutely try to measure trust either implicitly (e.g. from sentiment analysis) or using explicit questions.
I also know of at least one company that measures (or at least, tries to measure) "leadership trust" among their employees using surveys.
People also assess your productivity and the quality of your results in deciding whether to work with you, to ask you to join their team, to hire you, etc...
I would be surprised if you don't try to assess your own productivity and the quality of the results that you deliver. Neither of these may be easy to measure but I don't think you should be ignoring them.
Companies don't bother estimating worker productivity themselves. Rather they let employees make their own case, based on their work, using whatever data they can scrounge.
Definitely recommend Rick Rubin's book The Creative Act for a detailed glance into how wildly off the attempt to systematize and measure productivity is, in a creative context. https://www.amazon.com/Creative-Act-Way-Being/dp/0593652886
The mechanics of this idea suck for everybody.
Sometimes you have a candidate who is up to speed on your stack or one of its dependencies and can go from idea to implementation in a short time period but otherwise the math doesn't work.
A week of time with a mentor for one day over that time is probably enough to do a 2 day task if there are no difficulties when you consider lack of knowledge of the code base and interfacing with a new code environment.
So best case scenario you pay 3x for a feature whose mental state won't stick around and the interviewer has to find time to do a week of work while juggling their existing job (which could be job searching if nothing else).
You could say "but you would hire them after" but if we are talking about that late in the process probationary periods make more sense.
If you aren't sure they are a good fit (say 50% certainty) overpaying for a potential solution is bad and then wasting that much time on a solution also doesn't make sense.
That is why most practical things are less than a day of effort and not impactful on the product to avoid weirdness around NDAs/Copyright/proper payment.
And if you think meaningful work happens more often than every two days I wonder what software company you are working for... Breaking down tasks to 1 hour slots isn't what I would call a good use of resources...
> If 10x engineers truly exist, why do pay scales intra company not cover a 10x spectrum?
The value you produce presents a cap on how much you can earn, not a floor. If you want to capture that value you need leverage, high end SWEs usually don't have that leverage. The statement is wrong anyway, at companies like Google, pay ranges from 200k-10million+.
> Interviews will transition to be more real-world scenarios, perhaps within the customer's actual codebase
Many good companies already do this, it doesn't actually change the interviews that much. All interview questions my company has are taken straight from the codebase - the end result is a standard system design + leetcode style interview because we actually need to solve these problems somewhat regularly.
Other options listed that lengthen the interview process from the current 6-8 hour standard are off the table at any companies targeting top of market talent who won't put up with longer than standard interviews (makes it hard to get companies to compete for the interviewee).
Companies not targeting top of market talent will almost always ape top of market won't adapt because they are not generally tech first and thus simply want to adopt "industry best practices". The organizational incentives to do this are incredibly strong.
Small tech-first startups are usually the only ones who can muster the organization will to do something more original recruiting wise but will necessarily stay a small part of the market.
> Interview performance (at least for those hired) definitely does not correlate with on-the-job performance
Citation needed, every company I've seen try to do a large scale assessment of this has found that interview performance is positively correlated with on-the job performance[0]. (I've seen some actual data + studies, but not sure any of them are fully public). What does the author have to offer against this?
I'd encourage the author to think much more about the incentive structures of the actors involved here and try coming to some new (more interesting) conclusions.
[0] https://rework.withgoogle.com/guides/hiring-use-structured-i....
Ugh I can’t find the original source but this concept comes from a 2013 study from Google? Finding old stuff on the internet is hard. https://www.quora.com/Is-there-a-link-between-job-interview-...
Here's my desired review:
Entire team goes around and answers the question: who do you want to leave? Two strikes get another chance. Three strikes and they're gone.
Same with the boss.
Keep their job or replace em? More than three say replace the level up does a panel with the three.
During our last layoff the question for the managers was "if you could drop any headcount who would it be?"
We lost about 8% from that. Everyone I talked to said they were happy that the layoff got rid of the bad apples they knew.
This sounds like it might work as a one-time thing, but just imagine the second-order effects. Your annual reviews literally become Survivor, how could you ever prevent backroom alliances?
Long term the differences in productivity are clearly visible.
My point is more radical than “we all have the same productivity.”
The very concept of individual productivity is incoherent.
If I was an utterly mad billionaire who believed that I could hire top software talent and have them attempt to store physical objects in data. Not 'encode the schematics' or even 'encode the complete physical details' but such that it was possible to generate some hidden combination. Such an endevour would not be productive but the fault doesn't lie in the employees.
I think two questions are only needed: are people, teams, and organizations working on what they are supposed to be working on on the scale of weeks to months? Are they hitting acceptable milestones? And when I say milestones, I don't mean time-based ones, which are more often than not arbitrary.
artbitrary, yes. But also what the entire business world revolves around. quarterly earning calls, monthly finances, yearly budgets. It's arbituary, but those are period they pick to determine a bunch of stuff above the product itself.
> My suspicion is that [...] there will be a surge in our capacity to measure and evaluate real-life work performance.
Whoever you pay the most, is the most productive person in the company. Yes, that means you, the CEO, should pay yourself the most because you are the most productive employee...
Though not quite important to the main theme of the article, I wonder what area the author is referring to.
Imagine how poor management must be to think more lines of code == more revenue.
If your work is merely adding some feature factory or bug fixes, maybe there is a correlation.
What is HARD is to come up with endless rationals for why some people get way more that others.