Working in an agency development requires a considerable amount of flexibility when juggling clients and projects. Given the nature of software development projects, more often than not, we’re hopping onto an existing project rather than starting a project from scratch. Sometimes the process feels like changing drivers while a car is in motion. Luckily we have a few tools for keeping on track.
I’ve identified four key concepts for a smooth onboarding process. Each idea comes from my personal experience jumping onto an existing team and from discussions I’ve had with other Delivery Leads. The four concepts are planning, people, process, and potential opportunities.
Planning
Detroit Labs has been doing this for a while (over 10 years), and we’ve developed plans and tools for joining an existing project. One of our most powerful tools is our onboarding checklists. When you join a project at Detroit Labs we start by sending you an onboard checklist for that specific project.
Tools
One of the first things you’ll see on any onboarding checklist is a list of tools. Projects typically have preferred communication tools as well as some tools that are specific to the design or development work that is being done. This is also a great time to look at your project’s team agreement and see what it says.
It’s impossible to collaborate if you can’t communicate. Joining the team’s communication tools is one of the first steps to onboarding onto a project. Some popular tools are Slack, Email, Confluence, Jira, ADO boards, and Trello. I have used all of these tools in my time at Detroit Labs, and there are many more out there that might be a good fit for your project. Other project-specific tools can be where the work happens and not just for communication. Tools like Docker can be used for creating local dev environments, or Figma can be used for designing user interfaces.
Observe
“It is impossible for someone to learn what they think they already know.” ~ Epictetus
My top priority when I’m joining an existing team is to learn as much about the existing people and systems as quickly as possible without disrupting the team. It might seem counterintuitive, but for me this means a lot of sitting back, listening, reading, researching, and note-taking.
But why be so passive? If I see a problem, why don’t I solve it then and there? Isn’t it better to hit the ground running?
Sometimes it is. If I see an issue that might seriously affect the well-being of a team member, or poses a major risk to the project, I might speak up. But in general, my goal is just to observe. Whenever there’s a change in processes, there’s a risk of creating more change than the rest of the team is comfortable with.
Gemba Walk
One powerful tool for observing comes from Lean manufacturing principles: the Gemba walk. Gemba comes from the Japanese word genba which means “the actual place”. The basic idea is to get as close as possible to where the work is being done and observe.
I did a Gemba walk on my last project when I shadowed a Quality Engineer. I just sat and watched him work, while occasionally asking questions about his workflow and how he made some decisions the way he did.
Spending one-on-one time with a QE helped me better understand their role on our integrated project teams and a big picture view into how their role impacts the software development lifecycle.
I was able to use that understanding at a later time to identify a potential delay when discussing a new feature. A couple of weeks later we were discussing making changes to our project’s URL structure that could have created problems with automated testing tools. That time spent with a QE gave me insights into their process so I was able to identify a potential headache.
People
People are at the center of any project and carrying out a people-first approach to is important to us at Detroit Labs. As a Delivery Lead I try to bring that value into every project that I am a part of. It’s important for me to have an understanding of the people that I’m working with. Rapport is the cornerstone of developing this understanding.
Rapport
Rapport can help your team feel comfortable when bringing important information to your attention. Rapport helps you trust your team when you need them to step up to the plate. Lastly, rapport helps us form meaningful connections with the people we work with.
To work effectively with people the first step is to build a rapport. This can involve showing some vulnerability, but it’s often worth the risk. I’ve had tremendous success by setting up introductory one-on-one meetings with each member of the team. I use these meetings as an opportunity to get to know the individual and find out how I can work best with them.
I like to start these meetings with some basic personal information to break the ice such as where they live or how they came to be in this field. That feels like a good segue into more interpersonal work-related questions such as “What’s the best way for me to communicate with you?”.
A few other questions that have helped me work more effectively on a new project and get acquainted with my new team members are:
- If you could go back in time and train yourself on how to work on this team, how would you structure that training?
- What efforts of yours have you found most successful since you started working on this team?
- What’s one thing you thought would make a big impact here but did not?
Each of these open-ended questions gives the other person space to talk about their values and experiences as they relate to the project.
Finally, it’s OK to take notes when you’re first meeting people. I will often keep a window open to jot down little bits of information that someone might reveal during a meeting. There’s a great story about how Bill Clinton successfully used a notecard system to keep track of the people he met. That notecard system ended up playing a large role in his becoming Governor.
Process
Established teams typically have a few different processes in place. These processes were put together to address the needs that the team had at the time. Process provides consistency and structure to measure wins and losses over time through metrics.
Workflows
In this context, I define a workflow as “how do we take a needed unit of work that comes in, break it down, complete it, and then share it with the necessary people?”. A workflow can involve meetings, tickets, phone calls, emails, and many other “inboxes”.
A project might have multiple smaller inboxes (like a request for work that comes in an email as well as a stakeholder requesting a new feature in a meeting) but ideally, this incoming work will be compiled into a single inbox where the whole team can see what’s going in. Depending on the team structure, a product owner might take responsibility for putting the inbox together.
Rituals
In Scrum methodology, we have what is called Scrum Ceremonies. These are recurring meetings where the team comes together regularly. Some examples of scrum ceremonies are backlog refinement, sprint planning, team retros, and daily stand-ups.
While not every team uses Scrum, most have some similar ceremonies. These might be meetings with names like “weekly check-in” or “product demo”. It’s important to join these recurring meetings as a new member of the team. Of course, there are obvious reasons like your client will notice if you fail to show up for your scheduled meetings, but there are other reasons too.
Recurring meetings such as these can provide context to a project and opportunities to understand its history. These meetings were instituted for a reason. You can learn a lot about the history of a project just by asking why a specific recurring meeting was put on the books. Perhaps there was a regular problem that was popping up.
Some useful questions that I like to ask myself during and after a meeting:
- Is the meeting helping with this problem?
- Has it been resolved?
- Will the problem come back if the meeting stops happening?
- Could this meeting have been handled asynchronously?
- Was every person in the meeting able to contribute? When a meeting exceeds 8 people, it can be difficult for everyone to have a voice.
- Were the right people involved? This can sometimes mean reducing the headcount of the meeting.
Potential Opportunities
After you’ve observed the team and developed a rapport with your teammates it will eventually become time to make improvements. Now is your chance to show your competency and help your team develop.
I like to ask myself a few questions before I make a change for my team, some of them are:
- What problem am I trying to solve?
- How will this change address that problem?
- How will I know that the change is working?
- When should I check if it’s working?
Example scenario: Let’s say you’ve had a consistent issue with team members on the West Coast having trouble with making it to stand up on time. You decide to try scheduling a stand-up for one hour later. You bring the idea up with your team and they think it’s a great idea. You reschedule the meeting and start taking note of how many people are running late. After two weeks you notice that attendance has been a lot better.
Conclusion
By focusing on the four main areas of people, process, and potential opportunities, onboarding to a new team can be a smooth transition. Each of the components feeds into each other to create a process of continuous improvement. By being curious, asking questions, taking notes, and offering up new ideas you’ll be an integral part of your team in no time.
