4 ms·

I don't dispute any of this post. Actually, to be blunt, the fact that you think any of this is a retort to "pay people for the type of work you expect them to

I don't dispute any of this post. Actually, to be blunt, the fact that you think any of this is a retort to "pay people for the type of work you expect them to do" is deeply concerning. > reviewers assume they know best. You are probably more adept at running a grant-funded research group than me. I have no doubt. My concern here is ethical. I do think the average PI is in waaaay too deep to admit how horrible even the "good" PIs end up treating their phd students. So, in that sense, I do generally assume I know best. Not about how to do successful research. But about the true reality of how the people in those salt mines are being treated. On that note: of course all that non-core work is valuable! Incredibly valuable! And PIs should probably hire someone to do that work! At fair market wages! With accurate job titles and job descriptions! I agree with everything you're saying... except about who should do the labor and what they should be paid for that labor. I'm going to reiterate two sentences from my original post. >> Want a devops engineer? Hire a devops engineer ("systems scientist" or so on). Want a graphic designer? Hire a graphic designer. >>> ‘I’m a researcher, not a(n) X,’ with X∈ {software developer, designer, marketing person, artist, …} >> Sure, but here's the rub. What does everything in that set have in common? They make at least 2x+ the average PhD student and have much better benefits. >> If you want a "force multiplier" person in your lab, do your job: get a grant and pay a fair price for that sort of labor. PhD students are NOT ∈ {software developer, designer, marketing person, artist, …}. If they were, you'd be paying quite a bit more and/or getting far less exceptional candidates. Labs that have successful spin-offs are usually the worst about this sort of thing. They're running their research lab like a seedling incubator, but paying each of the one man shops printing their lottery tickets low five figures without retirement benefits.

lmeyerov 5y ago
My response is to the Reviewer #2 aspect of, instead of say championing a proposal on merit and, for their allocation issue, advocating for say increased budget for extra staff... rejecting it because of belief in Not My Job for something a good team would often either do scrappily or consider to be part of their job. One of the main costs and bottlenecks in modern academic R&D is the crazy low grant acceptance rates, forcing leaders to 5X grant writing time vs doing time, which makes this reviewer response 5X more nasty than you might otherwise think. If you want to go ethical - * PhD students, most of all, are learning how to do R&D: picking valuable problems, picking how to solve them, and most efficiently in time/money/etc solving then. Doing scrappy Day 1 work is very much a part of that skillset, surprisingly similar to a founding MVP team: Not My Job is teaching the wrong mindset and divorces you from the community + work, which may be what you are trying to learn. * ... However, Learning to Outsource/delegate is indeed part of efficiency training, so let's dig in. The default answer in most prototyping is do a crappy cheapo version, replace with a more costly version when it becomes the need, and reserve your shoestring budget for a few really important things. So likely no to a commercial grade design firm on rerainer, yes to either a $50 logo on Fiverr or more likely, something funny you can make via a free tool, done. Later, when there is more need and budget, say Year 2, easy to revisit. * Some things do merit staff. Should a bio lab partner with a CS team who wants to learn their needs as part of making new CS methods? That's T-shaped collaboration and good, and part of why academic teams can be so scrappy: there's ~always someone somewhere where your non-core work is their baby. Or, maybe they want to inhouse to get more speed/reliability/control. If that person will be like the CS team, ultimately making new CS methods, or a more computationally minded bio researcher helping with some of their own coding for faster EDA, great. But if they will always be Author #2 and has to code on projects they are not doing the science on, that's not a postdoc, that's a staff programmer. We should have more of those.

lmeyerov 5y ago

My response is to the Reviewer #2 aspect of, instead of say championing a proposal on merit and, for their allocation issue, advocating for say increased budget for extra staff... rejecting it because of belief in Not My Job for something a good team would often either do scrappily or consider to be part of their job. One of the main costs and bottlenecks in modern academic R&D is the crazy low grant acceptance rates, forcing leaders to 5X grant writing time vs doing time, which makes this reviewer response 5X more nasty than you might otherwise think. If you want to go ethical - * PhD students, most of all, are learning how to do R&D: picking valuable problems, picking how to solve them, and most efficiently in time/money/etc solving then. Doing scrappy Day 1 work is very much a part of that skillset, surprisingly similar to a founding MVP team: Not My Job is teaching the wrong mindset and divorces you from the community + work, which may be what you are trying to learn. * ... However, Learning to Outsource/delegate is indeed part of efficiency training, so let's dig in. The default answer in most prototyping is do a crappy cheapo version, replace with a more costly version when it becomes the need, and reserve your shoestring budget for a few really important things. So likely no to a commercial grade design firm on rerainer, yes to either a $50 logo on Fiverr or more likely, something funny you can make via a free tool, done. Later, when there is more need and budget, say Year 2, easy to revisit. * Some things do merit staff. Should a bio lab partner with a CS team who wants to learn their needs as part of making new CS methods? That's T-shaped collaboration and good, and part of why academic teams can be so scrappy: there's ~always someone somewhere where your non-core work is their baby. Or, maybe they want to inhouse to get more speed/reliability/control. If that person will be like the CS team, ultimately making new CS methods, or a more computationally minded bio researcher helping with some of their own coding for faster EDA, great. But if they will always be Author #2 and has to code on projects they are not doing the science on, that's not a postdoc, that's a staff programmer. We should have more of those.