22 ms·
To show my point with an example, according to him, 10 devs keeping the lights on has a better AAR than 15 devs that are keeping the lights on and adding new va
by boopboopbadoop 5y ago
To show my point with an example, according to him, 10 devs keeping the lights on has a better AAR than 15 devs that are keeping the lights on and adding new value. But the former is not more efficient than the latter.
- mavelikara 5y agoWhat is AAR?
- nsp 5y agoPretty sure they mean annual recurring revenue (ARR)
- mavelikara 5y agoThen this clause makes no sense: > 10 devs keeping the lights on has a better AAR
- boopboopbadoop 5y agoSorry, I meant ARR/FTE ratio, the metric that the article and the person I replied to are using.
- mavelikara 5y agoOk. If the 15-member team is adding value alongside the maintenance, that will surely be showing up as increased ARR. If the increase in ARR is > 50%, the 15-member team will be doing better in ARR/FTE. I don't still get your objection to the point made in the article.
- boopboopbadoop 5y ago> If the 15-member team is adding value alongside the maintenance, that will surely be showing up as increased ARR. No, and this I think is the root of my point. Anything not producing AAR yet (e.g. developing a new product) has no impact on your AAR, but adds headcount, thus skewing any insight AAR/FTE would give.
- mavelikara 5y agoThis point, I believe, is implied in the article. The trend of ARR/FTE is what the author recommends measuring as a metric.
- boopboopbadoop 5y ago> So, one of the few reasons to ask for the startup headcount is to compare to its revenue and quickly evaluate its soundness. This line lead me to believe otherwise. I agree the trend is more valuable, but still has issues (e.g. months- or years-long projects will have no value until they are released)