[somethoughts]

At least in my own small company - I'm hoping to promote the concept of the T shaped technical leader ladder.

You're rewarded/measured on two metrics - breadth and depth

- a depth metric - leadership in your own specific project team where you add features.

- a breadth metric - you've demonstrably shown that you've gotten other teams outside your own to contribute to your project effectively. Additionally and perhaps more importantly you must show that you can act in a supporting role on multiple other projects outside your own core project. Supporting other projects outside your core project include signing up for triage support, updating documentation, improving testing, etc. without frustrating the primary maintainers.

IMHO - focusing on depth as the only way to technical career progression leads to feature creep, ball of mud codebases with high barriers to entry and silo thinking.

Would be curious if/why this is controversial.

[zeroonetwothree]

I think both are important but it’s not necessary for any one person to excel at both. Some will naturally be better at depth and others at breadth. As long as you acknowledge both types of contributions I think it will work out well.

[somethoughts]

Good point! I think you're right.

So currently there are two narrowly defined options for career progression:

* technical leadership on core project/domain

* engineering management

Perhaps instead of eliminating the depth option for the technical track and making the T shaped depth/breath mandatory, just make it an additional option to provide an additional track for people to take for career progression.

* deep technical leadership on core project/domain

* broad-based technical leadership on core project/domain and supporting role on multiple projects

* engineering management

[sytelus]

You should reward only based on customer satiesfaction and adoption.

[somethoughts]

Agree - one feature that is missed w.r.t. long term customer satisfaction and adoption is long term support for previously delivered features. This is exacerbated when product managers/SW teams are mostly measured on new feature delivery metrics.

The full feature lifecycle and reducing bus-factor across the entire existing product feature set is rarely considered as its not generally captured in OKR metrics.

[gkop]

You could count the number of customer complaints. Oh wait, we’re talking about Google..