Onboarding new team members is hard!
In my career I’ve been involved in many projects, I’ve been in leadership positions, simple team member positions, and I’ve worked as a consultant to teams. One thing that I have noticed time and time again, is that adding capacity to teams is one of the hardest things to do, and it’s basically something that often we don’t give much thought to.
Focus is always on architecture design, use cases, sprints, scrums, acceptance tests.. databases.. cool new technologies etc etc.. we love to talk technology, play with new toys.. People, junior software developers.. bah.. whatever…
What are the problems that are inherent to onboarding new members to teams?
New team members are often junior, and don’t have the same skills as the “architects” team members.
Project documentation is often the weakest part of any technical project, it’s all in the architects “head”
Senior team members are often not interested in training or mentoring new team members, or just really don’t have the skills to train them.
Even more skilled new team members may not really understand how your software is organized.
I’ve seen many times where bodies have been thrown at projects, and it simply does nothing to advance the state of the project. Usually it comes down to the fact that people are not machines, you just can’t add people to a project and expect an increase in production. Actually in many cases, you see a regression in production as the team diverts effort to train new members.
So how do we onboard new team members? How do we make them productive as soon as possible?
The good news is that by simply exercising good software design principles, we can make onboarding of new team members much easier. One of the better techniques to promote better team building is layered software design!
I worked for a company where we did not have the resources of our competitors, we had to build a very sophisticated solution, and we one Senior Architect (me) and one intermediate developer, and the rest was interns, volunteers, co-op students.. and basically anyone we could get to work for us. There was a lot of churn in the team as people finished work terms, people found jobs, moved on etc etc.. We managed it by designing everything in layers.. (think of an onion).. Instead of building a monolithic huge piece of software, divide your solution into definable layers, and the key is, create an SDK for each layer.
The goal is to build something like this...
You can then allocate your most experienced people to the core, your next level to the services and so on.. The idea is that people can start on the outermost layer of your architecture, and then move to where their skills are a “best” fit.
SDK’s should be the goal, your downstream teams should be considered your “customers” as much as your real “customers”
This is not just about building layered software, that’s nothing new.. This should be about building a complete SDK between layers. What do I mean by this?
Samples of how you would accomplish some basic tasks.
This model fits in with the SaS (Software as service) model, that is quite popular right now, but we don’t have to limit ourselves to SaS. This principle is a logical principle, you can apply this to almost any software projects.. Each layer can be a library, a logical API within a larger project, web service, queues pipes etc etc.. It’s not about the technology stack, it’s about the idea of building layered software!
There’s nothing here that’s really all that revolutionary. In fact probably everything I’ve written is very obvious.. The main thing is that as architects, we often focus too much on solving the technology problem, we don’t often put much thought issues such as onboarding new team members in our designs.. Hopefully this article will make you think a little about this in your next project.