Prompt: Onboarding new teammates/myself
Amanda Snyder:
I’ve seen onboarding be most effective when everyone on the team helps to reach out. It’s too easy for a single person to forget to mention something, or for that person to become very busy and not have a time for an onboarding at the moment. When each team member takes a small part in helping out, then no single person gets labeled as ‘In Charge’ or ‘The Person to Ask’. This is important, because it sets the stage for teams where everyone does what needs to get done, and nobody waits for someone else to step up. It easier then one may think to get into the bad habits of ignoring easy wins because it’s ‘not our responsibility’, or ‘but so-and-so always handles that’. Onboarding should be approached the same way any part of the project is. If one person knows how to do everything and handles all the responsibility, the team won’t move forward if something should happen to them or if they get tied up. However, if the knowledge is a shared knowledge, and each person on the team is able to contribute to the onboarding, then smooth transitions are easy to make at any time.
I’d be the first to admit that I have been guilty of this in the past. It is sometimes easier to just step and take care of everything that needs to be done in one fell swoop. However, I have also felt the pain of later on assuming that if I were not around, then others would pick up most of the onboarding efforts. It does not work this way. I didn’t put in the effort to spread the knowledge and create the expectation that everyone was to help in the onboarding. It’s just as important that no one team member take too much charge, as it is for everyone to step up and help. Watch yourself to see if you are always the one to introduce someone to a project, and if so, make sure to ask others to help out while you can support the learning. Don’t wait till schedules fill up, time pressure increases, or you’re rolling off, and assume that others will know what needs to be done.
Linda Goldstein:
I believe that the most essential onboarding step is to immediately be introduced to every one of your new teammates; it is easy to accidentally ignore and offend even the most kindly and professional new teammates while you’re still gaping at this new space which you will be spending so much time in.
One of the most essential early onboarding steps is to get the new teammate all of the user access credentials that are needed to check email, push code, deploy, view+edit cards, etc. Forgetting or postponing this makes everything else into a ridiculous nuisance.
On the projects that I have been on, the same few steps always apply to solo developer onboarding. This is the stuff that I personally have to do before I can really “get” the code. Usually it is best to do this after hours or in gap time when you are not pairing.
- In 1-2 sentences, what does the project do, and why? Be able to explain this from memory.
- Clone the codebase as early as possible to a computer that you have access to after hours.
- Look thoroughly at the build script: what artifacts does it create? Can it generate a database, upload artifacts, deploy? Where does it get its dependencies from?
- Start from the main() (or index.html, or equivalent) of the codebase- follow one possible usage path all the way from the UI down to the lowest code layer you can find. (Repeat this several times)
- (If there is a database) Connect to the database. Look at every table. Look at the dependencies between tables. If you find any stored procedures, look up where they are called in the code.
- Fun activity: find a well-tested class. Delete the class and re-implement it using only the tests as a guide. When all the tests pass, compare your code to the original.
Aubrey:
To introduce people to the new domain, I’ve seen a mix of personal browsing-the-code, guided walk-throughs, and general overview sessions take place. In the last two cases, I think this has been most effective when the person being onboarded has contact and explanations from more than one source. Just as each person has a certain learning style, each teacher has a certain style in conveying important information, and will focus on different aspects, even when giving a general overview.
As far as resources to help onboarding, use of collaborative online tools to hold logins/ credentials, relevant documents to peruse, and contact information for talking to people with specific knowledge is great. The tools I am most fond of, however, include Trello, a collaborative card-wall system I use to track things I’ve learned, problems I faced and may face again, tools I want to use that I’ve seen others using, and handy things I should remember. As well, my very favorite tool that I think helps most with onboarding is literally a map of the land, a layout of how everything connects. With the whole project structure laid out, it is easier to understand how each part interfaces with the whole, and domain-specific knowledge becomes easier to apply.
Nikki:
I worked with a TWer that rolled on to our project and complained that we had not onboarded him thoroughly enough. Then when we got new people later on, he was very good at making sure that he took them through the system quite thoroughly so that they were in a better position than he had been. I was grateful that he improved the system, however my thoughts from this were (1) maybe he should have been asking more questions and (2) I don’t think that he ever succeeded in communicating about the culture - this could only be learned over time by just hanging around with the project members.
When I rolled on to my last project I paired with other BAs to test their stories, follow the steps that they had written in the acceptance criteria, and follow the steps in the automated tests. These things got me up to speed extremely quickly; it was a useful feedback for the stories as we discovered some things that had been missed; and I got to know the culture and the style of analysis that the team was following. BA pairing is good!
I would ask everyone to be able to quote the elevator pitch. Which means that we would have to have one in the first place. It would be nice if this was placed in the good news about delivery emails too!
Sarah:
So far the most effective onboarding I have seen is a quick introduction to the purpose of the project (elevator pitch style) and then introductions to everyone on the team along with what they do. After that, for devs, jumping in and pairing with people has worked out well. Although, so far the difference between whether or not they should be rotated or stay on the same story seems to have some contention. Thus far I would argue that rotating them through all the devs is a bonus since they see the system from many points of views as well as how their new team members work. By rotating them on to different stories, they should also be exposed to other team members’ work (BAs and QAs). Team activities during this initial period are also a huge boost for a good introduction to the team’s culture.
This all said, I believe the most important part is the quick explanation as to why the team is there. The rest can be picked up from being around and asking questions, but if the team as a whole does not have the same idea of purpose, it is easy to come off with the wrong impression.
Rebecca Sliter:
My thought process tends to mimic concentric circles, so I'll start with a microexample before expanding on the process :)
"What's your experience with [technology X]?" is the best thing I've learned to ask my pairs. On my first long-running project, I considered myself such a n00b that I figured whoever I was pairing with had more experience with the task at hand than I. Not so. It's always good to figure out where your pair's coming from.
Asking, "what would you most like to improve?" and, of yourself, "what should *I* improve?" are questions I've been using lately. It gives the askee (a teammate or yourself) ownership of the improvement. Generally speaking, we do better work when we're personally motivated to do so.
I often try to gain confidence by understanding a single part of my project, be it a functional area of the codebase or the team dynamic. Once I've ramped myself up to that I can onboard others as well. Pay it forward!
The ability to teach the team something is a great indicator of onboarding progress. Sometimes this means speaking up during a retrospective to solve an issue on the team. Other times this could be holding a lunch and learn, driving a refactoring, or helping the team get up to speed with a new tool.
These are vague, less-technical suggestions, mostly because I've realized that learning how to learn is the most difficult part of starting a project, a new language, or a workflow. The strategies I've mentioned help me to focus my approach to self-learning and/or onboarding a teammate.
Mangalam Nandakumar:
Joining a team as a new member especially when the rest of the team has been working together for a while, can be quite challenging !! For a business analyst this can be a little more challenging having to understand the depth and breadth of a project in a rather short time, and with limited opportunity to pair !!
The first thing I tell myself when joining a team is to not feel left out, and to try to not be daunted by all the jargons and friendly banter that the rest of team shares ! I keep reminding myself that it takes time to fit in (particularly if you are an introvert) and to just wait it out !
The next thing I do is to set realistic expectations for myself - if this is a long running project that I have just joined - I don't expect to be up and running in a week's time ! So I have conversations with the project manager, client principal (or anyone who sets expectations with the client about when I can be billable) to set this straight and to get an idea of what the landscape looks like.
As a business analyst probably replacing a BA already on the team, these conversations become very important - since they set the pace for how the transition and onboarding happen.
All things being sorted out, I usually start by testing what has already been developed. This gives me a good wide perspective of what the project does, gives me time to try and play with some functionality, make notes and observations, and maybe even uncover some defects !
I take this as a foundation for further conversations and delve into an 'inquiry based learning' mode where I quickly gather information about what I need to know rather than learning everything about the project - and that speeds up my learning curve!
The next best thing to testing, is to pair with the BA on writing some stories - I would like to jump into this as early as possible - since this helps me learn about what processes are followed on the team - how is the story structured? How involved is the client during this phase? Who in the team is involved in story kick-offs, etc. This again helps me ease into the team, and build relationships !
But there will be always be that one day, when teammates and the client will begin to trust you !!! That is the day you know you have been ‘immersed’ ! :)
Abby Bangser:
While I do not think that there is a definitive best way to onboard, there are two topics that I have identified so far as important.
The first is to set expectations. While you may know that the new person coming on is supposed to be rewriting your build pipeline by week 2, they may not realize that expectation. Similarly if you are the person rolling on and you know that this is a new technology you are working with, try to identify timelines with your team for when you will be self-sufficient. This can get tricky if you are rolling on in a leadership position, but it if its possible it would allow a lot more free communication.
The second topic is that of fitting in quickly. This can be as small as following the trends for lunch or being assigned a desk, but can be as big as getting access to the code base and actually throwing points during an estimation. Often times people will delay getting code access since there is pairing anyways, or hold off on estimations because they do not yet know the process and standards. This is valid, but can also set up an even bigger hurdle to onboarding. The more time spent on explicit “onboarding” through paperwork and presentations the harder it is to explain why someone is still unfamiliar with the file structure of the project when they are one month in.
Finally, while the concept of “I don't know what I don’t know” is real, the person onboarding is the only one that can know their learning style. Speak up about what it is you need so that you can contribute, and ask for it!
