It can be stressful joining a new development team. Whether you are a recent college graduate or an established practitioner, you want your new teammates to know you are smart and committed to success.
Unfortunately, the desire to be respected and show our abilities can sometimes work against us. There is a delicate balance between passionate engagement and trying too hard.
Through the past 8 years of working with agile development teams, I’ve observed what has and hasn’t worked well for new members integrating with an existing team. I’ve distilled my observations into 5 tips that I hope you’ll find useful.
1. Be Honest, Confident, and Humble
No one likes a know-it-all, and teams can’t trust someone who makes up answers when their knowledge is challenged.
Be honest about the knowledge and skills you do or don’t have. Be comfortable admitting to your gaps, and be eager to learn and grow.
Don’t try to guess your way through a problem. Don’t make assumptions about how or why things work. Be comfortable asking others for help or referencing documentation.
Be humble about your skills, and be willing to teach others.
2. Follow Before You Lead
Join a new team with an open mind, and learn their way of doing things before you try to show them how smart you are.
Be tolerant of practices that are foreign to your established approach. Before pushing for alternatives, gain perspective of the rationale for the status quo. Demonstrate that you are able to learn quickly.
Mastering established team practices and rituals builds trust. Your recommendations and improvements will have a greater chance of adoption after establishing a position of perspective and trust.
3. Serve The Team
Observe how the team works, and find a way to fix a significant pain point in a tool or process to better facilitate day-to-day development. Work outside of team hours to alleviate the pain point through automation or better tool selection. Surprise the team by introducing your solution and showing it to them during a morning sync-up.
For ideas, listen for grumbling about test frameworks, the build process, continuous integration, design asset integration, or reporting on project management metrics.
Be careful about how far you go. Automating an existing process is likely to be better received than making an independent decision to replace an existing tool. Work with an established team member if you plan on making significant changes.
4. Bring Solutions
Look ahead in the backlog for features that will impact the application’s architecture or present significant modeling challenges.
Spend an hour or two of your own time identifying how to model the problem and translate it to a technical implementation. You’ll be surprised by how much you can get done just thinking about the problem during spare time (waiting in line, taking a shower, cooking dinner, etc.).
Bring your ideas to the team when it’s time to discuss implementing the new features. Let people know you’ve been thinking about the problem, and ask them to engage in improving your idea. Be open to criticism, additions, or changes to your idea.
You don’t want to force your idea on the team. Remember that participation increases buy-in.
5. Be a Toolsmith
Spend some of your personal time mastering and enhancing tools the team uses. Learn tricks and shortcuts that improve the daily development experience.
Examples include:
- Create hooks that load the application environment into a REPL for hacking and ideation.
- Create IDE macros or scripts that generate stubs for repetitive code structures or files.
- Identify and showcase lesser-known features of frameworks or APIs the team is using.
Share tools freely, and allow other team members to help improve the tools you create.
Do you have any tips to share about integrating with a new team? What has worked well? What hasn’t?