1.) Create a spreadsheet with all of the features of your group's/company's products(s) listed in rows.
2.) Create a column for every team member in the group and highlight the lead developers for each feature.
3.) Then ask each team member to add a checkmark in their column for every feature for which they would be willing to be on hook for 24x7 triage pager duty.
Over the long term - the most valuable contributor(s) on the team will be the one(s) with the most checkmarks next to the features they led development on (i.e. they write understandable code and document well) combined with the most checkmarked rows in their column (i.e. they proactively seek to understand other peoples codebases).
Agree that there is probably room for improvement to such a process and still a great amount of subjectivity required and a presumption of good faith participants who aren't actively gaming the numbers.
In general though even if some developers are gravitating to only projects that are simple/trivial, those wouldn't necessarily be differentiators because such projects would have checkmarks by other developers as well.
Also it can help to have the Product Management team rank the features in terms of strategic importance and criticality to the functioning of the company.
I'd say the biggest benefit of such a spreadsheet is to provide visibility to leadership about the bus factor of the team. Too often the critical projects are really only maintained by a few team members. There's no incentive for new team members to learn the "legacy" projects versus creating their own pet projec. Then the inevitable RIF or transition happens and the lack of long term support becomes an issue.
> Couldn't there then be a risk that now some people want to avoid higher risk projects, and just build the simpler features, and get more checkmarks
This is kinda a well known phenomena in medicine[0]. Same with lawyers. I'm just reminded of this scene from Silicon Valley[1]. It's messed up and why everyone needs to be very careful with metrics and remember that metrics are only guides, not targets.
Kind of ignores the risk externalities have on projects no? If you tried your best to deliver something, but another teams priorities changed, or the business/market shifted, or the project got bogged down in planning/politics outside of that team members control, or if the team needs to integrate with a system (external or legacy) that’s out of their control and is notoriously flaky and torpedoes their velocity and morale.
1.) Create a spreadsheet with all of the features of your group's/company's products(s) listed in rows.
2.) Create a column for every team member in the group and highlight the lead developers for each feature.
3.) Then ask each team member to add a checkmark in their column for every feature for which they would be willing to be on hook for 24x7 triage pager duty.
Over the long term - the most valuable contributor(s) on the team will be the one(s) with the most checkmarks next to the features they led development on (i.e. they write understandable code and document well) combined with the most checkmarked rows in their column (i.e. they proactively seek to understand other peoples codebases).