By: Ivor Bakša, CEO
You have a new guy in the Dev Team, which is great, but if the guy is still “new” after one year then you can find yourself in the “we learned nothing” problem. I’ll be sharing some experience how we managed to increase knowledge transfer to less experienced developers by making a few simple changes to our software development lifecycle (SDLC) that in the end influenced the improvement of our company’s culture while also making our development teams even stronger. What you have at the start is experienced and less experienced developers. Other than sharing coding knowledge during coffee and occasional work on a project these guys don’t share much of knowledge. Not in a formal way. By introducing low level design and code review the guys started to improve their know-how.
The goal is to break project tasks (stories) into small, manageable tasks understandable to an experienced software developer as well as to a new guy. Low-level design goes deeper to the bottom of the software, on the data level, static diagrams (classes), data structures, methods. Breaking tasks like this is beneficial on many levels, but mostly for controlling your time plan and task list.
Important task
Don’t assign low priority tasks to new members, include them instead in your most relevant projects and tasks, give them a few low-level design tasks, and when they finish these, feed them some more. This way they’ll learn faster and feel like they’re doing something relevant. Don’t forget, they’ll try to prove themselves. Give them an opportunity to do so.
It’s a universe in a jar
Being in the IT world for so long, we often forget our first code check-in to the repository, our first meeting with a customer, our first talk about technical aspects of a project with more experienced guys, our first production deploys etc. Once you’ve gained experience, all these steps become a usual business, but for somebody new to the industry, it’s a completely new experience that keeps their senses on high alert. Let them have these experiences inside a great company culture with concise steps and hands ready to catch them if they slip.
Listen to people and encourage them to talk
Listen to your experts and your new members, encourage people to talk, it’s a crucial component of any improvement.
Detect on time when new guys need help, then try to help them or kindly ask someone else to help them. We’ve found that the best thing to do is to facilitate a small group meeting
(i.e. expert – developer or requestor – developer) after a daily stand-up (if you hold them).
1) It’s about respect
Be patient with your new guys and your experts. Say thanks, please and congratulate them when an opportunity comes. If the team members see you do it, they’ll treat each other the same way.
2) Unburden your experts
Unburden your experts as much you can. You don’t want to have “know-it-all Bob” or “does-everything Brent” (a reference to The Phoenix Project, a great book!). Whenever you can, give your experts more LLD and code review tasks rather than just coding tasks, and you’ll soon have more experts. Allow them to go home to their families and to work in a less stressful environment, they’ll be thankful for that and they surely won’t forget it.
3) Periodical checks
My recommendation is for you to check if a process is being followed, if LLD tasks are being clear to new guys, if code review has been done and to periodically check what the percentage of finished tasks is (comparing them to the deadlines). Talk to people inside the project to see if there’s something there that doesn’t smell right. This could be a project manager’s, Scrum master’s or solution architect’s task.
4) Empower people
Rather than micromanaging tasks, you should empower people to execute their tasks and fulfil their potential. It's not advisable to jump into tasks and get too much technical (regarding low-level design),
or to request too many explanations, regardless if you are a manager, solution architect, Scrum master or expert who’s not involved in the discussed tasks.
You should just facilitate the expert–new guy relationship, ask about task progression and provide help if needed. It sounds easy, but personally, this was the hardest lesson for me to learn.
Sometimes it’s easier to be a full-on manager, micromanage tasks and get involved on a technical level tasks (how to resolve something, what to do, etc.), but this level of involvement stops people’s
learning processes and causes distrust between an expert and a new guy.
5) Correct your mistakes
Learning is an evolutionary process; you won’t get there immediately. Our first LLDs were free forms (per each project and expert’s decision), then we moved to written forms (Word documents), then we
added task descriptions to change management tool (Jira), we tried with mentors (one per each new guy), code review was done only on somebody’s request, and in the end we added it as the final step before
code check-in. We moved miles from the starting point, and most importantly, the whole process was iteratively improved. Communicate with experts to get where you want to be. If you’re using Scrum,
a sprint retrospective is a good way of learning what could be improved, or daily stand-ups, if you’re a good listener.
What will you gain in addition to faster onboarding and a greater learning curve? You’ll gain trust building inside the team, more manageable tasks, better project risk management, higher communication between team members as well as increased mentorship and leadership skills of your experts. Another very important aspect is that the whole learning experience will turn your team members into experts on bits and pieces they were working on, turning them later on into mentors and leaders that are encouraging everybody to earn even more knowledge and respect. Good luck to you guys, hope this article was helpful. Please feel free to add your thoughts and views on the subject, let’s learn together.
