During my first six months at Atomic Object, I’ve had the opportunity to work on three projects. As a result, I’ve spent quite a while getting ramped up on new projects. Each project had different technical requirements, business domains, and team dynamics. As different as these projects were, there was one common denominator: the typical ramp-up activities didn’t really seem to work for me.
Aimlessly reading through documentation or exploring codebases can often feel unproductive. Likewise, constant pairing can leave a new team member feeling overly dependent on others and lost without them. Here are three approaches that will help a new team member feel productive and independent faster.
For the Project with a Business Model (or Tech Stack) that Makes Your Brain Hurt
It’s easy to assume that after enough time pairing on tasks or poking around a codebase, everything will suddenly make perfect sense. If that moment of clarity hasn’t happened yet, it’s easy to convince yourself to just keep trying a little longer without making any changes. That’s what happened with the first project I worked on.
Then, after about a month of nothing making sense for me, my team had an informal “knowledge transfer” to prepare for our tech lead moving to a different team. We spent most of the meeting creating a rough entity-relationship diagram.
This was extremely valuable to me. We made a printed copy of the diagram and referred to it daily — throughout the rest of my time on the project — when navigating tricky technical discussions.
I think many teams could benefit from a knowledge transfer meeting when a new member joins. It would both bring them up to speed and make sure existing team members are all on the same page. It would also help the team prepare for an actual knowledge transfer at the conclusion of the project.
For the Project with a Test Suite that Needs Some Love
A bunch of failing tests is never a good sign for a project, but it’s a good opportunity for a new team member to jump in. Making a failing test suite green again is a great task for a developer joining the team to tackle alone. Why?
- There are clear, small, and well-defined subtasks: get each test passing again.
- It requires digging into all different corners of a repository, which helps the new developer get a sense for the general project structure and observe patterns in the codebase.
- The work has a clear and important purpose, which allows the new team member to make a valuable contribution to the project right from the start.
This is a particularly useful task for a junior developer that hasn’t had much experience writing tests. They’ll learn the value that testing provides, they’ll gain a sense of ownership over the project’s tests, and they’ll push for good test coverage from everyone on the team.
For the Project with a Team that’s Just as Confused as You Are
Maybe you joined during an early research and design phase. Or perhaps there are a lot of unclear team dynamics and relationships to navigate. Whatever the reason, it can be pretty tempting to invest all your time into investigating unfamiliar tools or reviewing others’ work.
However, this can be dangerous. As you begin to find some answers, you also become aware of a handful of other topics to look into. And just like that, you find yourself stuck in a never-ending cycle of frantic information gathering.
Rest assured, there are better ways to get through the period of team-wide uncertainty. If you’re working with people outside of your company, identify key collaborators outside of your team and reach out to those individuals often. They’re likely a better source of information than the seventeenth consecutive article you’ve read on the subject.
If there aren’t any good sources of knowledge to get in contact with, that’s okay too. In that case, ignore all the reg flags attached to the unknowns and find something that you (or your team) do have some experience with. Start from there by documenting or implementing something familiar, even if it is low priority. It’s a concrete contribution and will narrow to a finite set the range of things needing to be researched.