Interesting management approach. My questions are:
1. How do you account for new team members in a team's metrics? A new junior dev will take some time to become productive so do you add the new member's progress to the team's metrics by making it responsibility of one or two experienced teammates? For instance, you might have internal progress indicators like - by month: 1 the junior should have read access to certain repos that are crucial to a good understanding of the application architecture; by month 2: made a certain number of commits; by month 3: written X number of tests etc.
2. How do you use these team metrics to recommend promotions and raises for individuals?
2. I don’t! Well, not directly. Team metrics usually have some impact on bonus money and raises, but that’s all based on budget so it’s not consistent year-to-year. Metrics should be used to drive behavior, but behavior should be used to determine promotion. Is the person a team player? Have they developed the skills necessary to be successful at the next level? What does the next level look like for them — is it management or engineering? A lot plays into it, and you have to have career path discussions with folks. Can’t solve this one with metrics :)
Businesses don't handle processes that produce variable outcomes very well since it opens them up to risk. Or stated another way, businesses love the notion of fungible employees and a one-size-fits all process to shepard those employees.
Fungible employees makes sense if you are in manufacturing where low skill workers are the norm, but not so much if you are in the knowledge industry, where there are variations in the skills each employee excels at.
IMHO, the dynamics of knowledge work is similar to a team sport like soccer/football but businesses would prefer that the dynamics be similar to manufacturing line workers.
Most of the time other people leave or move to other teams.
Being a decent human being is not about getting practical advantages - otherwise sociopaths would be the most helpful people around.
Instead, many large corporations want to instill a culture of competitiveness and often cynicism because competing is what they do.
Cooperation, lasting relationship between employees, mutual help, solidarity are increasingly scary words for many companies.
Sociopaths are exploiting the macro-level heuristics we've developed as a species to come to an immediate, reasonably-likely evaluation of safety, tending individuals toward trust, and danger, tending individuals toward defensive action. It takes knowledge and experience to differentiate between a good read based on sincere action and a bad read based on intentionally-deceptive action.
Sociopaths often will appear like the most helpful people around, and sometimes may actually be the most helpful people around, for the duration of the time that they need you to be on their good side. Then they'll dispose of you ruthlessly. If you don't pick up on the signals ahead of time, you don't find out until you've been backstabbed. If the sociopath is skilled, they ensure that you can't "come back from the grave" and cause problems for them.
It's not that corporations don't like cooperation in principle. From a high level, in fact, many corporations are actively and honestly trying to cultivate it. It's just that our systems keep the exploits too open to the relatively-rare maladjusted power player (normal people will sometimes flirt with the same tactics to avenge personal grudges, etc). This forces everyone into a defensive position, if it doesn't force them out of the game entirely.
Once an organ grows to exceed the direct influence of a very small handful of truly good and wise leaders (the more palatable tech word may be "visionaries"), it will inevitably mandate this weird perceptual bastardization.
So basically the long-term effect of these systems was me to slack on whatever my manager deemed important to get done to whatever extent I could while I did whatever would win me clout points with other developers or let me learn a cool skill.
I also got pretty jacked from sneaking off to the gym etc. Lol it was lit
Even on the team level you're still reading tea leaves if you're going into the issue tracking system. The only measure that should matter is execution towards a business goal. A team that is killing it consistently is doing the right things, or is being given the right projects.
This is why I generally dislike measuring individuals against specific metrics. I try to set individualized metrics for all of my direct reports — for example, if I had a developer who keeps checking in code without valid tests, code coverage might be a metric I track with him just to help him understand how he’s doing against his personal goal. Even within the same job description there is often room for a significant variation in technical and interpersonal skills, and you need a team with a good mix of both to be successful. A one-size-fits-all approach to individual metrics just leads to a team of people with the exact same skill set.
I think the way you measure teamwork is at the team level by having a consisitent set of team-level metrics the entire team is judged against. This means individual personality and career path variations don’t matter as much. I’m talking things like say, number of broken builds, velocity improvements, production issue counts, etc. These should be business outcomes that the product folks care about. If you make it the team’s responsibility, you’ll find teamwork happens more naturally.
This approach to performance management is in direct opposition to stack ranking, and a big part of why I refuse to work for a company that forces its managers to stack rank within teams. The question of “what makes a good employee great?” is so difficult to answer that if you have multiple high performers, it’s effectively arbitrary. It also tends to punish people who are maybe less technically brilliant, but have strong interpersonal skills (after all, how else does a mediocre programmer make it through a CS degree?) Those interpersonal skills often lead to better technical discussions and avoidance of miscommunication between technical folks.