Category: Onboarding Strategies (Page 1 of 2)

Its Purpose?
Every project has meetings or events that repeat. Sometimes they occur daily, others weekly and others less regularly. Sometimes they are informal and ad hoc, other times formal and repeated. It’s important for new people to understand what you call each of these rituals, how they work and why these rituals exist. Understanding what you call them, how they run and why helps them become a fully participating team member faster.

How Did We Execute It?
Before any repeating meeting we would have, if we had a new team member, I would explain what we were about to do, and explain the reason we met. Some rituals I didn’t explain in great detail how we would conduct the meeting since it would be faster to let them experience one. I intentionally explained it in front of the group to ensure we all had agreement about what we were all about to do, and to help remind newer participants why we have them again.

Here’s what it may sound like (you may of course, have different resons for running stand ups in the example below that are just as perfectly valid):

Explaning what: We’re about to start our “Daily Stand Up Meeting”.
Explaning how: In this brief meeting, we stand in a circle facing each other and share information that we think others will be interested in such as what we did yesterday, what we’re planning to do today, and most importantly any blockers we currently have.
Explaining why: We do this in the morning to help start our day and talk about what we did yesterday to helps others understand what progress we’re making. We talk about what we’re planning to do today to double check our priorities are correct for the day, and we want everyone to talk openly about our blockers because we want individuals to feel supported by the team in overcoming any blockers.

Here’s another example:

Explaining what: We’re about to meet for our “Tech Huddle”.
Explaining how: In this session, we want everyone to share an important lesson they learned today, or a gotcha others should know about
Explaining why: The system is becoming complex, and everyone may discover new things (or even old things over again). By sharing some important lesson or a gotcha, we accelerate the learning process and avoid costly mistakes caused by relearning the same thing over and over again.

Image taken from Ron Layters’s photostream flickr stream under the Creative Commons Licence.

Why Is It Important?

It’s difficult for team members to fully participate in rituals unless they understand what expectations you have for them and understand why it’s important to participate. Explaining what you call the ritual, and how you conduct each ritual and the roles team members play is a first step in the right direction. Once they understand the what and the how, the new people understand what the name of your ritual means to them and are now enabled with the ability to participate. Explaining to them the purpose of the ritual and the drivers behind it them helps build a reason for them participate.

Giving them both the ability (what the ritual is called, how it is run and how to participate) and the motivation (the signficance and value of the ritual) helps new team members stand out less by helping them avoid coping strategies of silence (“I don’t know what to do, so I’ll just sit and watch what others do)” or resentment (“What a crock! Why are they wasting my time?”)

You gain a secondary benefit from explaining the ritual following the what-how-why strategy. Explaining the what and the how helps you understand how consistently you repeat your rituals, leading to standardised work. Explaining the why helps you focus on the value of your ritual. Often many rituals lack value and, as a result, you should drop them.

What I Might Try Next Time
The next time I explain my rituals, I think I’m going to try to write what I say down to see if I’m being consistent. This might also work well as project documentation useful in handover to support or to observers who sit outside of the project.

Its Purpose?
Explicitly identifying code patterns in the code base as well as how and why they’re used helps new team members learn more about the system faster. Explaining the system in terms of well known patterns helps new team members identify variants and where patterns are being abused/mis-applied.

How Did We Execute It?
In trying to hand over some work to the support group, the team assembled a list of all patterns used in the system. We listed the pattern name, a reference to the pattern (either book or web link) and how it was being used in the system. We also wrote down the benefits or concerns each was bringing to the codebase. We listed each of these on the team wiki on a page called “System Patterns”.

When new people joined, I would print a copy of the wiki page, and then during or after walking through the System Architecture, helped them understand where they might use them or see them being used.

Image taken from Hubmedia’s photostream flickr stream under the Creative Commons Licence.

Why Is It Important?
Patterns are excellent vehicles for communicating intent and solutions to common problems. Identifying and explaining the system as a set of patterns helps new team members understand the system in much larger chunks, making it easier for new people to focus on absorbing incidental information. It also allows them to focus less on how the code works together, and more importantly focus on what the code does and what value it brings.

Well known pattern names help to identify common problems in the domain, and what the team’s general approach is for solving them.

The number of patterns also indicate a qualitative attribute of your system. If you have a very large system, and only a small number of patterns it potentially indicates that everything is done in very different ways and needs some refactoring. Alternatively if these small number of patterns are used everywhere in the system, then it could already be a very well refactored system. I would also consider looking at a very large set of patterns for a small code base as that might indicate over-design and excessive complexity. In both cases, I would watch out for patterns with only a handful of uses to see if they are actually useful or not.

Things To Watch Out For
Some new team members may not understand all the patterns used in the system. Giving them reading references helps though you may need to do more work to help them understand the pattern.

What I Might Try Next Time
I would revisit this list of patterns with new team members after they’d been in the code base for a while. I think although it’s useful to introduce the catalogue early, it would help to reinforce some of the larger picture after they’ve had an opportunity to discover more detail on their own.

Next time I would also try to link to some part of the codebase that implements the “ideal” version of the pattern and the benefits the team reaps.

Its Purpose?
Working with people closely on a day-to-day basis creates a safe environment, ideal to learning more about the current culture of the team including the norms, habits, style and general approaches to way things are done.

Image taken from ImproveIT’s flickr stream under the Creative Commons Licence.

How Did We Execute It?
On this particular project, programmers pair programmed most of the time. As a technical lead, I wanted to make sure people were comfortable working with each other so I encouraged a bit more of a pragmatic pairing approach and asked the team to take on the responsibility of ensuring enough pairing was going on.

I highlighted the benefits of what we were trying to achieve with pairing (knowledge transfer, style nuances, spreading different problem solving approaches, review of code) and asked new people to be comfortable raising flags when they were getting uncomfortable. Interestingly I think on this particular project we still ended up with a very high percentage of time spent pair programming and noticed that people also appreciated having a little bit more freedom if they wanted to investigate something.

Why Is It Important?
Working closely with someone (that you are bound to do with pair programming) gives a great insight into the working culture of the team that you happen to join. It’s easier to incidentally pick up the certain style that the team has towards different items though can be sometimes very frustrating depending on the people working on that team. I think that pair programming helps with the onboarding process, but it alone is not enough. I personally think that this technique is best combined with the Big Vision Business Problem, the Visible Architecture, and the Transparent Technical Debt strategies.

What I Might Try Next Time
I find pair rotation an interesting experiment. I’d like to try doing a day pair rotation with new people so that they more rapidly get a feel for the way individuals work and contrast their different experiences. Talking over their experiences and finding out what they discovered themselves or see what important lessons they found could be very powerful. I’d be quite concerned about over-doing it though.

Its Purpose?
This strategy gives individuals a chance to gain some context and do some background research before actually arriving on the first day of the project.

Image taken from Shinyai’s flickr stream under the Creative Commons Licence.

How Did We Execute It?
Before we started our new team, I sent out an email that covered a few different topics. Some of the content would repeat some of the information they receive during other onboarding activities but I think it was still useful to help set some expectations. Some of the topics that I covered included a list of all the tools that we use, the technology stack that the application is built on, a description of common software patterns that we leverage in the system and an opportunity for them to reply with some questions.

Why Is It Important?
People coming to your project may come from very different backgrounds. They may not have had the same level of skill, or exposure to the same sets of tools. When you send out a concrete list of items relevant to your project, you help them understand what they may need to do more reading on or where they need to develop further skills. It also helps alleviate any concerns about not having the right level of skill or understanding and gives them more context about the project.

What I Might Try Next Time
Next time I would want to include more about the business, include more on what life on the project is like, and discuss any unusual or unique aspects to it.

Its Purpose?
This helps people new to a project answer questions about the domain more effectively and where the system fits into it.

Image taken from Kakutani.com’s flickr stream under the Creative Commons Licence.

How Did We Execute It?
We followed domain driven design as much as possible applying several techniques described in the book. We aimed for a Ubiquitous Language, reducing the number of terms for the same thing to a single one. This flowed into the code as well, where domain terms were used for domain classes, and namespaces for related concepts.

We tried to model all of the business processes and rules in a domain layer (the inner most tier on an onion ring model of our system), so that they were easily testable and people knew the first point to look for when answering a question about the domain. A side benefit of this is not tying the domain rules to a particular choice of technology or framework, and makes inconsistencies in the domain much more visible.

Many different factors affected the way in which we coded including aspects from Domain Driven Design, Object Oriented Design (such as encapsulation, responsibility, decoupling and reuse), testability, and readability. Our standards by default exclude comments where possible replaced by representing as much intent as possible in the code itself. We focus on what it does and why. I’ve found “What” tends to be best represented by production code, whilst “Why” is better explained in tests because you can better represent different contexts there.

Given that I’ve been with the project for some time and seen quite a few people flow on and off, I believe that given a handful of system patterns and a high level picture of how it fits together, it’s much quicker to bring people on board. Equipping them with knowledge of where to find information and seek answers for their own questions, you spend less time answering questions and it fits much better into their own mental model.

Why Is It Important?
Following Domain Driven Design and well refactored code brings many more benefits than just effective onboarding (think flexible, adaptable and much more robust and consistent) though I want to specifically focus on its impact on onboarding for the purpose of this entry. Even though these are great development practices, an emphasis on both of these has such a significant positive impact on onboarding of people.

Enabling others to find the answers to their own questions is much more effective because they depend less on others to work out their mental model and help them fill the gaps in that model.

Its Purpose?
Many of the techniques I’ve written about are ideal for covering a broad range of people and a broad range of topics. Each is useful for their own particular purpose, but I feel it important that you understand who you’re onboarding, and customise each of your techniques or at least the way you execute them to help them become more effective.

Image taken from Dogwelder’s flickr stream under the Creative Commons Licence.

How Did We Execute It?
Although everyone on our team went through many of the same onboarding strategies and techniques, I sat down with each new person to find out a little bit more about them. I found it important to ask questions such as:

• What do they want to get out of the project?
• What have they accomplished that they’re particularly proud of in the past?
• How do they think they learn the best?
• What are they worried about?

Each of their answers don’t immediately necessitate the change to any session, but it gave me a much better idea of how I should adapt it, or expand on the session in the way that best suits each individual.

Why Is It Important?
Everyone that I’ve worked with is very different – some learn more effectively in different ways, and many have very different backgrounds and experiences. I feel it’s important as a coach to understand where they come from, and their different needs, tailoring content and the way information is conveyed to their particular style. Some people feel that the Socratic method is always an effective technique, though is often executed in a way that can be patronising and demeaning, particularly for more experienced people. Telling war stories or success stories is sometimes more effective, with the little anecdotes sticking in their memories. For others, visual techniques for conveying information is the most effective way they can learn. Others just need to do it themselves.

In short, there is no “Golden Hammer”, so don’t try to use it on everyone.

Its Purpose?
Individuals progress through different stages of learning. Not everyone will progress at the same pace, and at some point, people will move beyond the initial learning stage and will start to learn more if they are doing it by themselves with less explicit direction.

Image taken from Ruojo’s flickr stream under the Creative Commons Licence.

How Did We Execute It?
As individuals new to the team demonstrated more knowledge and understanding about the system, we started giving them more ownership of a particular story card. They would create the Tiny Tasks for a story, and own the design for it. As the technical lead, I would only intercede if they wanted an opinion about a particular design, other than that they would be given space they needed to finish a story card without any explicit instructions.

Why Is It Important?
There are many different ways that people learn and many different models describing each way. In Aikido, they describing learning using Shu-Ha-Ri and is one often used as an analogy of learning software concepts and patterns. Another model talks about the 4 Stages of Learning where an individual progresses from Unconscious incompetence towards the ultimate stage of Unconscious Competence though may progress via two others stages of Conscious incompetence and Conscious Competence. The common theme between most learning models is recognising an initial stage for a person who needs explicit direction and further stages where explicit direction is no longer required.

Many of the onboarding (and really just learning) techniques help address most of the initial stages (Shu or Unconscious Incompetence) of learning and it’s important to keep in mind that individuals will reach the second stage at different rates. If you continue to apply the same approach to teaching students who have transcended to the next level, you will find they become more resistant, and less appreciative and more than likely much more argumentative and resentful.

The key to Letting Go is recognising when individuals progress to that next level and give them the appropriate freedom to accomplish specific goals with little to no guidance. It’s important to still create a safe environment for them to make mistakes but they will learn much more by doing it themselves.

Its Purpose?
Acting as a teacher, coach or mentor helps to reinforce the concepts on all the different subject matters you cover whilst mentoring, therefore turning a student into a teacher is an opportunity you should make the most of. Vocalising your opinions and thoughts on a particular subject works to further deepen your understanding of the topic matter. It also has another benefit of exposing any gaps you may have when your student asks you questions.

Photo taken from Golbog’s photostream on Flickr under the Creative Commons license

How Did We Execute It?
We’re lucky enough on our project to pair program and we’ve found it an extremely effective technique at spreading knowledge about the system. When are team formed, we co-ordinated some strategic pairing, understanding that we had people at various stages of learning about the system. We made sure that people who’ve been working on the system pairs with people newer the system, effectively positioning them in the role of a “mentor” for newer people.

Why Is It Important?
Continuous cycling between student and teacher are common patterns you see in all types of martial arts classes because they recognise the importance of putting a student in the position of a teacher. Often you see many of the senior students instructing newer students on how to improve their technique even though they themselves haven’t yet achieved mastery.

Teaching others is an important part of the learning cycle, strengthening and deepening the things that you think you know so it’s important to create these opportunities and take advantage of them where you can.