As a long-time Thoughtworker, I have had the privilege of working on many projects and with a diverse set of teams. Moving from one team to the next helped me observe and learn how to co-exist and thrive in several (interesting) groups of technologists! I have broken down my experience into 8 tips to follow when joining a new team. While most of these suggestions are from a consultant’s perspective and are within the context of moving between teams, they apply to someone moving into a new job or role as well.
The first step to being accepted in a new team is getting to know all the members. As is expected, I use the first standup to get to know my team mates and try to memorize their names and roles.
Taking the time to informally interact with each team member is a good way to ensure a good rapport. I often begin conversations with a mention of hometowns and families - this acts as a starting point to share interesting anecdotes, find common ground, and get comfortable.
It’s also a good idea to participate in team activities like lunches or the occasional board game. I joined my current team after my maternity leave and was working part-time for the first few months. While this did not give me much opportunity to socialize, I did try my hand at an occasional team game of foosball or go out to lunch when time permitted. The fun conversations helped me be a part of the team sooner rather than later.
"I listened more than I studied, therefore little by little my knowledge and ability were developed." - Joseph Haydn, Austrian composer of the Classical period.
Listening is a necessary soft skill and being new to the project is a great opportunity to exercise this skill. I have learned to use my first few days on a team, to understand domain specific terms, the language, stakeholders names and designations, the team’s current work and about the peripheral services/teams that we collaborate with. Taking notes helps me go back and clarify something or simply retain the new knowledge.
I’d advise you to use your initial days in the new team to focus on the details of the project, processes and tech that’s specifically needed for your role. For instance, when I joined my first team at Thoughtworks, the developers addressed the Java class names by their abbreviations during design discussions. PIM would be PipelineInstanceModel and SIM would be StageInstanceModel and so on. I gathered quite early on that other than the terms or concepts you might be familiar with, there will always be a number of abbreviations and jargon used at the table which you’ll need to get the hang of. In my current team, SOS is not a distress signal but is Structured Object Storage!
A new joinee to the team is usually briefed on what the team does and what role is expected of them. However, key to success is clearly understanding the finer points of these expectations. Let me share an instance with you - when I joined Thoughtworks I discovered that irrespective of seniority or experience, I needed to be completely involved in the project, question decisions, understand business value, be aware of code quality etc. This was not the practice at my previous organization where depending on the domain and project's scale and team structure, an individual’s actual role varied. Here’s an example of that, one of my colleagues who was a team lead on one project was expected to share responsibilities with a more experienced (client side) tech lead on her next project - not a usual practice.
It makes a world of difference when you take the effort to clarify what’s expected of you as a team player by talking to your tech lead or manager. This will greatly influence your approach to day-to-day work, your interactions with colleagues and stakeholders and the kind of information you prioritize as you ramp up.
In my experience, what really impress new teams is a fast ramp-up! For a developer, that equates to understanding domain basics and the tech stack fast enough to be able to contribute to story development. When in a new team, I proactively track the completion of all planned sessions rather than push that responsibility on to them. I’ve also started documenting all that I’ve learnt in a shared space (if it does not already exist) as onboarding documentation, so that new team members can benefit from the repository.
An important characteristic of a quick ramp-up is proactively obtaining all the necessary credentials and access to relevant systems, so you have easy access when learning or performing tasks. In one of my teams, a couple of new team members focussed on acquiring the right knowledge to start contributing to the project but were negligent of interacting with the support team to get their credentials sorted out. And, when it was time to actually work on their first story, they were unable to commit code with their own credentials which was unacceptable to the client.
"Who questions much, shall learn much, and retain much." - Francic Bacon, an English philosopher, statesman, scientist, jurist, orator, and author.
When people hesitate to ask questions, it negatively affects their learning curve. They don't effectively grasp the project scope and associated processes and activities which hampers productivity and self-confidence. Avoid all that and ask questions! I make it a habit to ask questions during training sessions, standups, tech huddles, discussions and especially when pairing with other team members. Having said that, I’m mindful of not disrupting ongoing work or discussions.
I have been lucky to have worked with brilliant yet approachable colleagues who have been considerate of my queries. But, there are times when questions are not entertained. In such cases we need to identify alternative methods to find answers. It was while collaborating with a client team that I learned that it was not encouraged to walk up to a colleague and ask questions during work hours. I started noting down all my doubts and would check for time with them via chat tools like Slack. They seemed more comfortable with the arrangement and I got the information I needed.
Making mistakes is an obvious part of learning that focuses on continuous improvement. I have heard stories from several long-term technologists about mistakes made in the early stages of their career. This included a rather surprising instance of committing code that caused an embarrassing production defect. However, what was consistent in these conversations was the technologists' take away from such instances - of learning and moving forward.
Also, some of us might have personal commitments that do not allow for the kind of time self-study requires. In such cases, seek a team member’s help to prioritize and pick important topics and try something I did - get to the office earlier than the rest of the team and use the extra time in the morning to read and learn.
If you have accumulated considerable experience from working on several projects, it’s highly possible that you can visualize multiple improvements by observing the code base, documentation, processes or practices in your first few days on the project. However, before understanding the complete background and context of the business problem being dealt with, suggesting or modifying the solution isn’t putting one's best foot forward.
A few years ago, I was on a team that worked on maintaining and enhancing a legacy product. And, when this new and experienced team member joined us, he questioned the choice of every tool and library being used. He was not aware that all these suggestions and choices had already been discussed with the client - who did not take them forward because the proposed changes proved complex and expensive. While the team wanted to explain this to him, his domineering approach was a cause for friction. My suggestion? After doing the homework, make your project-related suggestions at the appropriate time with the appropriate person.
Exhibiting the qualities of ownership and responsibility from the very first day translates into having made the effort to know as much as you can before-hand. Once you feel confident, ask for tasks that you can accomplish alone. This will help you be known for your proactive and responsible approach - both highly valued in an agile project team
I have a great story to share on displaying ownership - the build time for our project’s source code was high and we wanted to change that. After an analysis, we recognized that we needed to change our mocking library (RhinoMock) as it was hindering parallelizing tests and reducing build time. This transition involved changing more than 500 files, which also was a reason for it to keep being de-prioritized. Around the same time, a new team member joined us and learned about the issue. He spent his initial time on the new team writing a .net app that would convert test files using NSubstitute instead of RhinoMocks. This tool helped us prioritize this particular piece of work and leverage it in our very next iteration. The new team member’s actions showed that he cared about the product and was ready to take ownership of its quality.
A new team, role or job are interesting opportunities to meet new people, have new experiences and learn new skills. It can be daunting too, and my hope is that these 8 pointers are able to help you navigate those crucial first days.
Know your team
The first step to being accepted in a new team is getting to know all the members. As is expected, I use the first standup to get to know my team mates and try to memorize their names and roles.Taking the time to informally interact with each team member is a good way to ensure a good rapport. I often begin conversations with a mention of hometowns and families - this acts as a starting point to share interesting anecdotes, find common ground, and get comfortable.
It’s also a good idea to participate in team activities like lunches or the occasional board game. I joined my current team after my maternity leave and was working part-time for the first few months. While this did not give me much opportunity to socialize, I did try my hand at an occasional team game of foosball or go out to lunch when time permitted. The fun conversations helped me be a part of the team sooner rather than later.
Observe and take notes
"I listened more than I studied, therefore little by little my knowledge and ability were developed." - Joseph Haydn, Austrian composer of the Classical period.Listening is a necessary soft skill and being new to the project is a great opportunity to exercise this skill. I have learned to use my first few days on a team, to understand domain specific terms, the language, stakeholders names and designations, the team’s current work and about the peripheral services/teams that we collaborate with. Taking notes helps me go back and clarify something or simply retain the new knowledge.
I’d advise you to use your initial days in the new team to focus on the details of the project, processes and tech that’s specifically needed for your role. For instance, when I joined my first team at Thoughtworks, the developers addressed the Java class names by their abbreviations during design discussions. PIM would be PipelineInstanceModel and SIM would be StageInstanceModel and so on. I gathered quite early on that other than the terms or concepts you might be familiar with, there will always be a number of abbreviations and jargon used at the table which you’ll need to get the hang of. In my current team, SOS is not a distress signal but is Structured Object Storage!
Understand expectations
A new joinee to the team is usually briefed on what the team does and what role is expected of them. However, key to success is clearly understanding the finer points of these expectations. Let me share an instance with you - when I joined Thoughtworks I discovered that irrespective of seniority or experience, I needed to be completely involved in the project, question decisions, understand business value, be aware of code quality etc. This was not the practice at my previous organization where depending on the domain and project's scale and team structure, an individual’s actual role varied. Here’s an example of that, one of my colleagues who was a team lead on one project was expected to share responsibilities with a more experienced (client side) tech lead on her next project - not a usual practice.
It makes a world of difference when you take the effort to clarify what’s expected of you as a team player by talking to your tech lead or manager. This will greatly influence your approach to day-to-day work, your interactions with colleagues and stakeholders and the kind of information you prioritize as you ramp up.
Ramp up. And quickly.
In my experience, what really impress new teams is a fast ramp-up! For a developer, that equates to understanding domain basics and the tech stack fast enough to be able to contribute to story development. When in a new team, I proactively track the completion of all planned sessions rather than push that responsibility on to them. I’ve also started documenting all that I’ve learnt in a shared space (if it does not already exist) as onboarding documentation, so that new team members can benefit from the repository. An important characteristic of a quick ramp-up is proactively obtaining all the necessary credentials and access to relevant systems, so you have easy access when learning or performing tasks. In one of my teams, a couple of new team members focussed on acquiring the right knowledge to start contributing to the project but were negligent of interacting with the support team to get their credentials sorted out. And, when it was time to actually work on their first story, they were unable to commit code with their own credentials which was unacceptable to the client.
Don’t hesitate. Make mistakes and ask questions.
"Who questions much, shall learn much, and retain much." - Francic Bacon, an English philosopher, statesman, scientist, jurist, orator, and author.
When people hesitate to ask questions, it negatively affects their learning curve. They don't effectively grasp the project scope and associated processes and activities which hampers productivity and self-confidence. Avoid all that and ask questions! I make it a habit to ask questions during training sessions, standups, tech huddles, discussions and especially when pairing with other team members. Having said that, I’m mindful of not disrupting ongoing work or discussions.
I have been lucky to have worked with brilliant yet approachable colleagues who have been considerate of my queries. But, there are times when questions are not entertained. In such cases we need to identify alternative methods to find answers. It was while collaborating with a client team that I learned that it was not encouraged to walk up to a colleague and ask questions during work hours. I started noting down all my doubts and would check for time with them via chat tools like Slack. They seemed more comfortable with the arrangement and I got the information I needed.
Making mistakes is an obvious part of learning that focuses on continuous improvement. I have heard stories from several long-term technologists about mistakes made in the early stages of their career. This included a rather surprising instance of committing code that caused an embarrassing production defect. However, what was consistent in these conversations was the technologists' take away from such instances - of learning and moving forward.
Self study
The ramp-up that I mentioned earlier refers to learning about the project and processes quickly enough to start contributing to the project. During this process, you will suffer an explosion of information. You might not have the time to carry out a deep dive and setting aside time to learn about the domain, technology, architecture and more will help.Also, some of us might have personal commitments that do not allow for the kind of time self-study requires. In such cases, seek a team member’s help to prioritize and pick important topics and try something I did - get to the office earlier than the rest of the team and use the extra time in the morning to read and learn.
Don't impose your views on others
If you have accumulated considerable experience from working on several projects, it’s highly possible that you can visualize multiple improvements by observing the code base, documentation, processes or practices in your first few days on the project. However, before understanding the complete background and context of the business problem being dealt with, suggesting or modifying the solution isn’t putting one's best foot forward. 
A few years ago, I was on a team that worked on maintaining and enhancing a legacy product. And, when this new and experienced team member joined us, he questioned the choice of every tool and library being used. He was not aware that all these suggestions and choices had already been discussed with the client - who did not take them forward because the proposed changes proved complex and expensive. While the team wanted to explain this to him, his domineering approach was a cause for friction. My suggestion? After doing the homework, make your project-related suggestions at the appropriate time with the appropriate person.
Demonstrate ownership
Exhibiting the qualities of ownership and responsibility from the very first day translates into having made the effort to know as much as you can before-hand. Once you feel confident, ask for tasks that you can accomplish alone. This will help you be known for your proactive and responsible approach - both highly valued in an agile project teamI have a great story to share on displaying ownership - the build time for our project’s source code was high and we wanted to change that. After an analysis, we recognized that we needed to change our mocking library (RhinoMock) as it was hindering parallelizing tests and reducing build time. This transition involved changing more than 500 files, which also was a reason for it to keep being de-prioritized. Around the same time, a new team member joined us and learned about the issue. He spent his initial time on the new team writing a .net app that would convert test files using NSubstitute instead of RhinoMocks. This tool helped us prioritize this particular piece of work and leverage it in our very next iteration. The new team member’s actions showed that he cared about the product and was ready to take ownership of its quality.
A new team, role or job are interesting opportunities to meet new people, have new experiences and learn new skills. It can be daunting too, and my hope is that these 8 pointers are able to help you navigate those crucial first days.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
