New Team Members
One of the age old issues of new members joining a project/team after the team has found a rhythm and started delivering, is that the new member always find issue with the SDLC that’s in place. This isn’t surprising since the new team member is often unaware of the history of decisions due to not being told the full history of the project, or that the team has forgotten why certain things occurred a certain way. This leads to a few thoughts:
- Voicing opinions is good, as long as they lead to concrete improvements. Voicing opinions just for the “hell of it” is like throwing stones at a glasshouse. If you are now living in the glasshouse, you are going to get hurt at some point.
- Existing working relationships are already in place for the existing team. New team member’s trying to do “their thing”, be it coding style or other, will cause friction with the existing team. Working with the existing team is going to be far more productive in the short term, and will not alienate.
- Respect needs to be earnt. This requires time to embed into a team, learn why decisions have been made, understand the current roadmap, and only then propose improvements with solutions.
- Showing an improved way of solving a problem with code is easier that talking about the proposed solution with engineers.
- Consider the next new team member, and what needs to be put in place to ensure they become productive faster than the last new team member