The best way to enable effectiveness for developers joining a new team
Motivation
Before people can become senior software engineers, two of the mountains they need to climb bear the names “software design” and “development methodologies”.
When people join a new team or a new company, there are also always new things to learn about the company spirit and how certain processes and tasks are handled.
These newcomers can be of any skill level. Senior software engineers, too, struggle when joining a new environment and need to get familiar with the team’s methodologies.
The usual ways
Usually, people get a whole lot of documentation and meetings, describing the desired processes and ways of working, when joining a new company.
Software engineers often learn through failures, discussions (e.g in code reviews) or reading books, attending conferences, and applying the learned stuff hopefully somewhere in a real-world project.
Problems with the usual ways
When documentation is handed out, it is often outdated, not read completely or processes are lived in different ways than described.
Learning through failures is a good thing and will never stop. But a lot of failures have already been experienced by other people, and learning from their mistakes can prevent repeating them. Also, most product owners don’t want to sacrifice their projects for the developers to have a learning experience.
Books and conferences provide a lot of theoretical knowledge of how specific things are handled best (in the opinion of the author) — the same goes for blog posts like this one.
Even if practical examples are provided, you’ll always have to find out how to apply the knowledge to your current situation and if it is a good fit in the first place.
Reviews are an excellent way to learn from other people in the company. The problem with reviews is that the developer gets the feedback only after a certain feature is completed.
At that point, design changes are already applied and would mostly take a lot of time to re-do if they are not appropriate. Due to this double-work, the code is often kept as is during code reviews (see sunk cost fallacy) and only comments for the future, the naming of symbols in the code, or advice for syntactic sugar are left if the code is working.
Not to mention the new joiner's bad feeling when suddenly their whole code gets rewritten because “things are done differently here”.
Dealing with the problem
Some people might already guess my recommendation for these kinds of problems. My approach would be to tackle these problems via a co-creation methodology, such as pair-programming, mob-programming, or co-designing.
Co-creation approaches are not only used in software development. They could also be applied in other fields like UI/UX design.
Why is this approach so beneficial? — Co-creation approaches not only transfer knowledge in a bi-directional way. They are also a social exercise to increase the team spirit and (especially for new joiners) validate if the character is an absolute fit for the team.
Doesn’t this cost double the time as letting people work alone? — NO! According to this research by the University of Utah, a pair-programming approach takes approximately 15% more time, but also leads to a visible increase in the quality of the outcome.
This increase in quality will (in software engineering) support the theory of going fast by going well and lead to a more consistent development speed in the long run.
A practical example
Coming back to the original problem statement of providing the best knowledge transfer to newcomers to a team (and/or company):
A newcomer could get a fixed “mentor” for a specific period (depending on their seniority).
This mentor should make himself available to the newcomer, and dedicate most of their time towards supporting the generic knowledge transfer and guiding the co-creational process.
Jumping into co-creation as early as possible also serves the rest of the team, as the impressions of the newcomer are new and memories of how things have been handled at previous teams are relatively fresh.
This means that the team could also learn from the newcomer and if needed (and approved by the team) adapt some processes or tools.
After the first entry phase, when the mentor has the feeling the newcomer “arrived” in the team, the intense mentoring should be reduced to leave room to breathe.
The pragmatic approach
We don’t aim for 100% pair-programming when someone is integrated into the team.
It is up to the mentor, the tech lead, or even the whole team (i.e. in a planning meeting) to decide which tasks should be paired and which ones are solo work.
I recommend always pairing for new features, conceptual work, or refactorings. — For all people, not just newcomers to the team.
This way, ideas can be discussed during creation, changes can be integrated fast (we won’t require a code review in these cases) and duplication of work is prevented.
It could also happen that someone is working solo on a bug ticket (or sth. else) and finds out that the task will take longer than expected or include some restructuring in the code. — It is then appreciated to ask for a pair as early as possible, to immediately get a second opinion on the approach.
There can also be tasks where changes to the domain model or complex process diagrams are worked out in a co-design phase and then implemented in a solo session. In these cases, the co-designer needs to be available in case the created design is not working out as expected. The team trusts the solo worker in these cases to raise hands if such a situation occurs.
Achievements
We achieve multiple goals with this approach (also for different involved personas):
- The newcomer interacts as close as possible with the team, builds up knowledge, gets introduced to common sense (and maybe also to some pitfalls), and gets to know the team and the system the team works with
- During the initial mentoring phase, the newcomer should get the skills to also become a mentor and guide the next person joining the team
- The mentor checks the setup documentation and improves on mentoring others
- The team can check alternative approaches that come up during discussions with the newcomer and learn/improve if necessary
Also important: A co-creational process is an additional methodology. It is not replacing existing conventions, such as documenting the system.
It might improve these things because multiple people might look at it simultaneously.
Conclusion
Co-creational work like pair-programming is an extremely powerful methodology for providing an efficient and interactive onboarding to people (especially developers in this example) of any skill level.
The benefits of pair programming go well beyond that. They include learning, innovation, fewer bugs, quality code, productivity, business resilience, and good team relationships (when done well).
— Dave Farley
It is not only about junior developers learning from experienced colleagues. There are patterns and pair combinations that are very efficient, depending on the goal that should be achieved.
For our onboarding approach, pairings with almost anybody can be done. The person the newcomer is paired with should already have a wide understanding of the team's domain and a similar skill level. Slightly more experienced at its best.
While long co-creational processes might be a bit exhausting, they are a kickstart to enable trust across the developers and produces warm, happy welcomes to our efficient software development teams, but also frictionless handovers of software projects to other development teams.
