Yes, what I was trying to say was that in my opinion the word ‘Scalability’ is a good match for 80′000 Hours stated definition of Solvability. In practice, Solvability and Tractability are not used as if they represent Scalability. I think this is a shame as: a) I think Scalability makes sense given the mathematical intuition for ITN developed by Owen Cotton-Barratt, and b) I think there is a risk of circular logic in how people use Solvability/Tractability (e.g. they judge them based on a sense of the marginal cost-effectiveness of work on a problem).
I agree that ITN/SSN are clearly framed as frameworks for problems not projects.
I agree with your examples in your point 2. I’m not sure if you’re making a larger point though? For projects we can just define scalability as: “if we doubled the resources dedicated to this project, by what fraction would we increase its impact?”.
Regarding your point 3, for me “How big would the impacts be if the project were successful?” and “How large can this project grow to while remaining somewhat cost-effective?” are the same thing in practice. That is, my natural instinct is to define success as expanding to the limits of reasonable cost-effectiveness. I would say this is scale at the ‘solution-level’.
“How big a problem is this aiming to tackle?” is different, of course, as it’s at the ‘problem level’.
By the way, you can also define scale as “How much impact has this project had so far?”.
However you define Scale if you then divided it by the amount resources invested to achieve that scale, you’ll get an ‘average’ cost-effectiveness. But, to get the marginal cost-effectiveness you need to factor in Scalability, because as the project grows its impact per unit will generally be declining. Whether we call the marginal value being closer to the average good ‘solvability’ or good ‘scalability’ seems like a matter of taste.
In any case, my goal with these comments is mostly just to agree that Scalability is important.
Yes, what I was trying to say was that in my opinion the word ‘Scalability’ is a good match for 80′000 Hours stated definition of Solvability. In practice, Solvability and Tractability are not used as if they represent Scalability. I think this is a shame as: a) I think Scalability makes sense given the mathematical intuition for ITN developed by Owen Cotton-Barratt, and b) I think there is a risk of circular logic in how people use Solvability/Tractability (e.g. they judge them based on a sense of the marginal cost-effectiveness of work on a problem).
I agree that ITN/SSN are clearly framed as frameworks for problems not projects.
I agree with your examples in your point 2. I’m not sure if you’re making a larger point though? For projects we can just define scalability as: “if we doubled the resources dedicated to this project, by what fraction would we increase its impact?”.
Regarding your point 3, for me “How big would the impacts be if the project were successful?” and “How large can this project grow to while remaining somewhat cost-effective?” are the same thing in practice. That is, my natural instinct is to define success as expanding to the limits of reasonable cost-effectiveness. I would say this is scale at the ‘solution-level’.
“How big a problem is this aiming to tackle?” is different, of course, as it’s at the ‘problem level’.
By the way, you can also define scale as “How much impact has this project had so far?”.
However you define Scale if you then divided it by the amount resources invested to achieve that scale, you’ll get an ‘average’ cost-effectiveness. But, to get the marginal cost-effectiveness you need to factor in Scalability, because as the project grows its impact per unit will generally be declining. Whether we call the marginal value being closer to the average good ‘solvability’ or good ‘scalability’ seems like a matter of taste.
In any case, my goal with these comments is mostly just to agree that Scalability is important.