“People may, but good data never misleads”
Let’s first see what I would want in a team member before going into analyzing one on the basis of data:
My Best Individual Team Member Is:
- Fully understands SOLID principles
- Loves their technology stack
- Writes great code
- Writes unit tests
- Adheres to OOP
- Understands patterns
- CI/CD mindset and proficiency in tools for the same
- Understands quality as well as delivery
- Loves ownership
- Understands client requirement
- Well managed
- Has team spirit
My Worst Individual Team Member Is:
- Mediocre developer:
- Does not follow coding principles
- Writes unintelligible/cryptic code
- Does not comment their code
- Hates the technology they are working in
- Does not write tests (thinks, it’s tester’s job)
- Waterfall development mindset
- Does not understand quality
- Overshoots deadlines most of the time
- Poor communicator
- Does not want to change
- Runs away from ownership
- Not interested in anything
- Doesn’t respect team
A software development project team usually consists of senior and junior SDE (Software Development Engineer) and SDETs (Software Development Engineers In Testing). Engineers could also be grouped as per their focus area(s) – front end,back end, or full stack.
I would approach evaluation of individuals like so:
Data Driven Evaluation Of The Team
Passive Evaluation (for every individual)
- Go through their resume. List down their experiences, skills, future goals. Also note if the experiences, skills, and individual’s future goals align with the projects’ and company’s related requirements.
- Go through final project reports of all the completed projects by the individual in last 6-12 months and prepare following matrix:
- Performance level – great, good, average, sub-par, bad
- Consistency of performance levels (70%+ is good)
- Change adaptability on the basis of diversity of projects undertaken
- Code quality consciousness
- TDD/BDD/AOP experience and comfort
- Positive/negative impact of individual’s contribution on budget and/or delivery of the project
- Go through a sample of code (committed in repo, in production or ready for the same) and collect following data:
- Complexity of the feature (could simply be a number between 1-10)
- Quality of the code
- Test coverage
- Clarity of style and adherence to company/industry guidelines
- Considering information gathered in aforesaid sections, observe them in scrum meetings on the basis of following criteria:
- Ownership level
- Story-wise performance; code quality and velocity
- CI/CD mindset level
Active Evaluation (For every individual)
- Schedule individual meetings with top performers (could be just friendly/informal meeting to avoid any kind of fear of performance evaluation) and gather following information:
- Source of motivation
- Code quality standards at individual level
- What are their future goals – near and far
- Individual tools and techniques they use to perform well consistently
- Would they volunteer to mentor an under performing individual
- Schedule individual meetings with worst performers (should be just a friendly/informal meeting to avoid fear) and try to understand following:
- Run thru the code and try to understand their level of realization about problem in their code?
- Have they been aptly communicated about their short comings?
- Reason of consistent sub par performance
- Understand if it is a work-individual fit problem – management style, technology match, etc.
- What do they think are the ways in which they could improve their performance in next X months?
- Would they be willing to be mentored by another member of the team?
- Suggest some training courses related to weaknesses and threats.
Individuals who have not been performing well should be given a fair chance to improve. Good performers should be encouraged to perform even better.
If someone keeps on performing at sub par level after giving sufficient time to improve, they should be asked to find some better fit out of the team/organization ASAP.
The matter of individual training wholly depends upon company policy. If company provides training resources and bears the expenses, under “fair chance to improve” policy individual should be provided training and reevaluated after designated period. If company does not have a policy of providing training individuals should be guided about how they could improve themselves in the required areas.