SourceCred and resilience to opportunists

[decentralion]

How To Get Promoted

This article has a lot of interesting information on how opportunities maneuver within corporate structures:

Company metrics have momentum and lag. Nearly all political behavior exploits these two properties. A metric in motion tends to remain in motion. Changing that requires good decisions, a lot of luck, and application of enormous force. And observing a metric is like observing light from a distant star— you’re observing the work done in the past. So opportunists don’t worry about any of that. The winning strategy is to ignore company metrics completely and move between projects every eighteen months so that nobody notices.

Wouldn’t people notice anyway? Rank and file employees will, but not the management. In a fast growing company things change very quickly. There is a hurricane of activity. New projects and teams are constantly spun up, products launched, reorgs, valuations, office moves, new hires, funding rounds, customers lost and gained, offsites, PR victories and scandals— nobody can keep track of all of this. You can’t remember what things looked like two weeks ago, let alone last quarter. Two years ago? Forget it! So long as you looked good at the time, nobody will remember what you did in your last role. And even if they do, people tend to attribute everything to the present. If you screwed up a project, switched roles, and it’s only now apparent that the project is in trouble, the blame will naturally fall on its current leader, not on you.

This makes me think that SourceCred-enabled organizations may be significantly less vulnerable to hijacking by opportunists than traditional organizations. Because our Cred is retroactive, if an opportunist is skilled a pivoting between projects but leaves giant messes behind them, it will catch up with them. Their Cred in past activities will depreciate, reducing their economic rewards and their political influence.

Thanks to @wchargin for sending me this article.

[AL0YSI0US]

@decentralion

Because our Cred is retroactive, if an opportunist is skilled a pivoting between projects but leaves giant messes behind them, it will catch up with them. Their Cred in past activities will depreciate, reducing their economic rewards and their political influence.

I ask the following questions openly, ( not directly to @decentralion whose response I welcome) but rather to anyone who feels called to respond.

Is there a method in place for viewing the depreciation of cred in past activities?

• Is / can it be interpreted visually on the cred graph?

I’m also curious what factors determine if a contribution is no longer of value to the overall product?

I can dream up writing a bugfix, PR or an epic say to adopt a new dependency, package or signing up with a new carrier, etc that is adopted for a while, and then maybe a year later it no longer serves the end product’s needs…this scenario makes sense to me because I can apply it to a storyline I can imagine.

• Since we dabble in the nuances I am curious where/ how one would find or measure value while pondering the depreciation metrics.
  • Another question that comes to mind is:

At this point in time how does the community value the different branches or categories of the project?

• Is this primarily/partially based on signaling?
  • If certain project tasks hold certain values upon completion of say: a whole feature, how would an individual know what those values have been assigned?

This makes me think of the term boosting which I have heard reference to a handful of times but am unsure of if I am grasping it in its entirety. I understand it as someone is interested in having something created so they flow additional grain to it sort of like upping the overall payout of the task and that motivates individuals to hone in on the task and complete it. Am I close?