I have been working in the world of software development for more than 15 years, this has allowed me to share experiences in several teams and in each one I have learned something new from the adaptation process, so here I am bringing you some tips and tricks to improve your onboarding as much as possible.
Strange as it may seem to you, our first steps will not be with technical objectives, but much more human.
The best approach in this whole process is that, at the beginning, we should listen rather than talk since we will still lack context on the decisions made earlier. We can write down all the improvement areas we see in a constructive way, we can suggest little by little and see the reaction, and then iterate as continuous improvement. In addition, we can help to document and/or review the documentation that the team has built.
The process consists of six parts: we will start with a presentation; then, at the same time, we will make a small discovery of the state of the team (product, dynamics and technology) and we will align expectations with each one of them. Once we are ready, it will be time to code.
An honest and transparent presentation. Even if they know you, the team may have never interacted with you as much as they will from now on. For example:
|
Hello, I’m Ramon, I consider myself blunt and transparent, my DISC defines me accurately:
Red: impatient, result-oriented. My least favorite thing is to be in a meeting where I cannot contribute or that makes me feel I am not contributing to the corporation, such as a meeting without a clear objective or expected outcome. Yellow: I don’t like routines at all and I find finishing tasks difficult. Nevertheless, my green and blue are very low: I care very little about processes and I struggle with active listening (I am working to improve it). In addition, I enjoy receiving feedback and improving constantly. I like that, when they think of me, they see the image of a good professional, someone with a lot of energy and eager to help. |
To do something like this you need to know yourself very well and it will help your team immensely to empathize with you. It would be a great idea if the team did the same exercise for you and introduced itself in the same way. It can help you to use tools like DISC or Enneatypes to look for adjectives in which you see yourself reflected.
The first step is to know the product that exists around the team. The person in the product role will play a big role here. Some questions that may work for you are:
- Who is the customer using the product (internal or external)?
- What would happen in the company if this team did not exist?
- Which are the medium/long-term objectives?
- How do we receive customer feedback?
- What is the client’s pain?
- What components define the product and what are they trying to mitigate?
- What is the vision of the product?
- Who are the stakeholders?
- How are our US? Do we have DoD, DoR?
- How do we score the US? Is there a template?
- What is our product roadmap?
- How does the business department envision the product?
We will have more information about the context of the team by understanding more about their expectations and needs for the product.
Now we can focus on the rituals or dynamics of the team: dailies, weeklies, retros… In this way we will have a general idea of all those moments where the team comes together to share ideas. We can ask about each session:
- Do we use any agile framework? Scrum or Kanban?
- What is its purpose?
- What roles do they play?
- Are they regular or on-demand?
- What are the dynamics?
- What parts does it consist of?
- Do we use any decision-making patterns?
- Who is leading it?
And we finally got to what all of us who work in technology love: the technology. To make an initial discovery of the technology we can use tools that other people have created and we know that they work. In this case I recommend the Software Delivery Assessment by ClonfluxDigital that allows you to have an overview of several areas that concern the team. You may come across a team that has done something similar in the past, let’s use it to understand what state the team is in. I recommend you to focus on understanding everything at a high level, as trying to cover everything at once can create frustration and become very complex for your team.
To complement all of the above, you can ask:
- What is the code life cycle?
- Which environments do we have and what use do we have?
- What tests do we use (name) and what components do they include?
- Are there any programming, style or design guidelines?
- What languages, frameworks and important third parties do we use?
- Do we have CI/CD?
- How do we deploy applications?
- Is there infrastructure as code?
- Is there a technology improvement backlog?
- Do we have ADRs?
Remember that we need to align expectations throughout the process. We can review how the team works, how they interact, what challenges they have and what is the energy between the members. At the same time, we need to know how we can make an impact. This way we will know much better which are the team’s needs (both product and technological) and what they expect us to do. By doing that, we will avoid surprises in the future such as: “I was expecting to do blah, blah…”. For this reason, it is useful to ask, for example: “How do you think I can help you?” or “What do you think I can improve?.
Now it’s time to code, the long awaited moment. Techniques such as Pair Programming or Mob Programming, and us assuming the role of driver, can help us obtain more context. During the whole process of entering the team involving the code, it is best not to judge it nor the technological decisions made at the beginning. Instead, it is best to ask beforehand, as there is for sure a reason to be as it is. To give feedback to your colleagues you can ask yourself questions like:
- What part of the code is most difficult for you to understand?
- How “painful” is it to run a project on a local machine? What about testing?
- How difficult is it to access the different environments of the equipment?
- How difficult is it to understand the IQ pipeline?
- How “painful” is your first deployment?
On the other hand, remember that the technological decisions that the team made in the past were based on the knowledge of that moment and within a specific context, so they may not make sense now, but they are still valid.
…
Throughout the process we will probably be looking at areas of improvement, so I recommend that you ask questions before sharing. Be empathetic and highly constructive. So, instead of saying “This is wrong…” or “I would do it this way…”, it would be more constructive to say something like “We can review this point, maybe we can find an improvement…”. Keep in mind that the team may have a backlog of work and it may not be possible to absorb it all at once.
As you can see, the process of joining a team is full of questions. From here it would be a good idea to arrange one on ones, if we haven’t already done so with all the people in the team, to understand more about their needs and see what we can bring to each person in a different way.
From here, progress within the team and collaboration with us should take place during the cycles of continuous improvement, using feedback sessions, spaces for reflection and revisiting those expectations.
