Estimated reading time: 7 minutes
When you first join a team as a software engineer, it can be both exciting and overwhelming. It’s natural to want to show your skills and how you can contribute to your new team.
As a fresh eye, you’d see empty gaps in the team processes, meetings, code-writing methodology, or system architecture. This provides ample opportunity for you to introduce new ways of working or innovations.
While onboarding documentation can be helpful, true integration goes beyond just checking off tasks. It’s a journey of building meaningful relationships, grasping the bigger picture, and understanding how your unique contributions fit into the team.
1. Trust and believe in the team you joined
In order to start your onboarding process on the right foot, you must enter your relationship with your new team with trust. It’s an essential foundation.
Trust in your new team should be established at the interview stage – it is here where you should ensure alignment and notice red flags.
As a valued new team member, you have a wonderful opportunity to build trust. To do so, listen attentively, communicate clearly, deliver results consistently, and actively contribute to the team’s goals.
A team is functional because one member trusts another to do their part in a new feature you are building. A designer trusts that the front-end engineer will bring their design to life, and the front-end engineer, in turn, believes that the back-end engineer will implement the necessary infrastructure.
2. Ask clarifying questions
Ask clarifying questions to avoid confusion or ambiguity so that you may understand a topic better. Most often, you ask these questions when you receive an unclear instruction or need to understand someone’s point of view.
A good rule of thumb for clarifying questions is to make sure they’re not probing. The question should not express a bias or opinion. It should aim to understand the “why” instead of the “why not.” For example, if you’ve come across a feature you feel isn’t implemented well, instead of saying, “Why is this not implemented like so?” you could ask, “What criteria informed the current implementation?”
To be able to ask clarifying questions, you need to trust the person. This means you believe they have a sound reasoning behind everything.
3. Understand the product
To join a new team seamlessly, you have to understand the product(s) the company has built. To build this understanding, you’ll most likely have onboarding calls with developers, managers, designers, etc., read available documentation, and ask clarifying questions. Another way to learn about the product is by shadowing stakeholders (product researchers, customer success managers, sales representatives, etc.) during client meetings.
A non-negotiable onboarding call is with the product manager or owner. This is an opportunity for you to build on top of what you learned during the interview phase and should give you a high-level understanding of the product.
It helps a great deal to explore the product as a whole – test and play around with it. It does not matter if you are a back-end or full-stack developer. Interact with the product like a user and try to understand from a user’s perspective. This would help you adopt a user-focused mindset during development and enhance your contributions to product-related meetings such as refinement.
Learning Kotler’s Model, which enables building or improving products or services to meet customers’ expectations could also help.
By familiarizing yourself with the product, you understand what a customer expects from buying the product.
More like this
4. Understand high-level objectives and team’s priorities
Every successful team has a common goal they are working towards in a given time. This could be monthly, quarterly, or annually. From a manager’s perspective, team goals provide a clear expectation for each team member, highlight the team’s contribution to the organization, and facilitate professional growth for team members. Your job as a new team member is to understand these goals.
It’s crucial not to undermine or doubt these goals as they were made with some reasoning – however, clarifying questions are welcome. While these goals were set before you joined the team, you’d have the opportunity to contribute to shaping the next set of goals.
A document typically outlines the team’s priorities for a specific period, such as a product roadmap or technical debt priorities. You can review these documents to understand the team’s focus. If the document is not available, feel free to ask any team member or your manager about the current priorities.
Once you understand the team’s high-level objectives and priorities, you’re almost ready to implement your first ticket or feature.
5. Learn the processes
Team processes are actions team members perform to combine their resources, knowledge, and skills to resolve their tasks and achieve collective goals. These processes differ by team, even when these teams are within the same organization.
Team processes are not about delivery. Instead, they are about how team members leverage each other’s strength to get stuff done. This could be how the team members interact with each other or external team members.
An effective team process helps a team achieve more with less effort. Agile frameworks are one example of where you can get up to speed with processes – do the team follow Kanban, Scrum, Extreme Programming, or something else? It’s essential to know and understand it. If you are unclear about any of the processes, ask questions. These sorts of process questions will be good to ask in interviews or before joining the team or accepting an offer.
6. Implement your first push to production
Now that you understand the processes, you already know how to navigate through your first push to production.
Start by understanding the feature you’re required to implement. Good managers or team leads will help you take your first few tries at shipping slowly with uncomplicated tasks. Despite this, your first push might still require thorough research and thinking.
If you are updating an existing feature, try to understand other features plugged into it, both from product and engineering perspectives. Don’t be afraid to ask around if you have doubts or gaps in knowledge.
After nailing down the nitty gritty, you are ready to plan implementation details. Think about how your intended solution will improve metrics like performance, integration, usability, data integrity, etc. Run your ideas by the team to get a feel for how they’d implement it or ensure you did not miss an edge case.
Implement your solution and deploy it to production using your understanding of the processes as a guide.
7. Note the loopholes or chances for improvement and suggest them to the team
When onboarding, it’s natural to encounter areas where processes, codebases, or workflows could be improved. These improvements can range from communication inefficiencies to outdated methodologies, gaps in documentation, or even redundant or unoptimized code structures. As a fresh set of eyes, you bring a unique perspective that long-standing team members might not have. However, it’s crucial to approach these observations thoughtfully.
Start by documenting any loopholes you have encountered. Instead of immediately offering feedback, take the time to understand the reasoning behind the existing setup. Ask clarifying questions to learn why things are done a certain way and whether the team has already considered alternatives. Certain technical, organizational, or resource-based constraints may be behind these decisions.
Constructively present your suggestions to the team when you feel confident in your understanding. For instance, you could say, “I noticed that our test coverage is a bit low in this area. Would it be worth considering adding more automated tests to ensure greater reliability?” or “I found this part of the documentation unclear. Could we add a section for clarity?”
Timing and tone matter, so choose moments where the team is open to discussion, such as retrospectives, 1:1 meetings, or after you’ve gained some trust by delivering your first few contributions. Always remember that your suggestions should align with the team’s goals and priorities, and be prepared for the possibility that not every improvement will be immediately actionable.
By presenting your feedback in a positive, solution-oriented way, you’ll be more likely to gain buy-in from your teammates and make meaningful contributions to the team’s processes and overall success.
Final thoughts
Each step highlighted above is focused on successfully integrating you into the new team while building trust and understanding.
Rather than immediately focusing on fixing what you perceive as problems, take the time to learn, ask clarifying questions, and adapt to the existing workflows. By trusting your team, gaining a deep understanding of the product, and mastering the team’s goals and processes, you’ll be better equipped to contribute meaningfully.
