Why do we need to measure productivity? No one seems to ask that question. To me it seems that trying to measure the individual (people) parts of a system in some quasi-reproducable and transitive way does more harm to the total output of the system than good.<p>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.
Because it's not observable; it has to be inferred. Every employee affects the finished product through a complex web of interactions. As a latent variable, we can only hope to gain a noisy estimate.<p>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.
Creativity follows a different pattern than highly repeatable line work. Software engineering is an inherently creative pursuit, especially when paired closely with a dynamic product function.<p>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. <a href="https://www.amazon.com/Creative-Act-Way-Being/dp/0593652886" rel="nofollow noreferrer">https://www.amazon.com/Creative-Act-Way-Being/dp/0593652886</a>
> Interviews will transition to be more real-world scenarios, perhaps within the customer's actual codebase, addressing a genuine problem the customer faces—possibly even compensating the interviewee for their time<p>The mechanics of this idea suck for everybody.<p>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.<p>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.<p>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).<p>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.<p>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.<p>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.<p>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...
Lot of poorly thought out stuff here, I suspect the author is young and lacks real world experience running a business.<p>> If 10x engineers truly exist, why do pay scales intra company not cover a 10x spectrum?<p>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+.<p>> Interviews will transition to be more real-world scenarios, perhaps within the customer's actual codebase<p>Many good companies already do this, it doesn't actually change the interviews <i>that</i> 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.<p>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).<p>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.<p>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.<p>> Interview performance (at least for those hired) definitely does <i>not</i> correlate with on-the-job performance<p>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?<p>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.<p>[0] <a href="https://rework.withgoogle.com/guides/hiring-use-structured-interviewing/steps/read-googles-internal-research/#:~:text=Structured%20interviews%20are%20better%20at,hires%20across%20functions%20and%20levels" rel="nofollow noreferrer">https://rework.withgoogle.com/guides/hiring-use-structured-i...</a>.
Measuring productivity is silly. Measure results.<p>Here's my desired review:<p>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.<p>Same with the boss.<p>Keep their job or replace em? More than three say replace the level up does a panel with the three.<p>During our last layoff the question for the managers was "if you could drop any headcount who would it be?"<p>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.
Currently I’m following the idea that it starts with good work priorization. With other words: What work shall an organization/team/individual actually execute? Which tickets shall be picked from the infinite stream of tickets? How do you know that the right tickets are picked? Unless this questions can be answered, measuring the individual performance is completely impossible in the short term. One can „work hard“ and produce a lot of code, write many tests, do many tickets with low ROI and still achieve subpar results. Thus the measure of productivity must truly capture the added value of one’s work. And there is no „one size fits all“ solution.<p>Long term the differences in productivity are clearly visible.
From the OP: “every potential metric..is woefully inadequate”. How many years do we keep trying before realize there is no such thing as individual productivity.<p>My point is more radical than “we all have the same productivity.”<p>The very concept of individual productivity is incoherent.
Putting aside the obvious Goodhart's Law implication productivity isn't just based off of the "components" be they human or otherwise but also the fundamental goals which control the end product.<p>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.
What even is productivity?<p>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.
I like the article's premise. I would like some argument for why we'd suddenly get better at measuring something that has escaped us for at least 80 years when knowledge work became more common.<p>> My suspicion is that [...] there will be a surge in our capacity to measure and evaluate real-life work performance.
It is quite easy. Just apply the income = productivity hypothesis that economists seem to love.<p>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...
> recursion is extremely rare in shipped code but extremely common in interviews<p>Though not quite important to the main theme of the article, I wonder what area the author is referring to.
It’s easy to measure productivity. Take all the profits and divide by all the hours worked.<p>What is HARD is to come up with endless rationals for why some people get way more that others.