Innovative and Ever-Changing industry
When I asked ChatGPT to describe the IT industry, the first point mentioned was "Innovative and Ever-Changing". But what exactly lies behind this overused phrase? It’s often applied to the tools, technologies, and work methodologies shaping the industry. While that’s accurate, this statement can be expanded further.
What’s also innovative and ever-changing are the projects themselves and the overall nature of work in IT. A developer working on the same project for 10 years or more is almost unheard of. Compared to other industries, project rotations in IT are far more dynamic.
Commit within the first week
The title of this post suggests that a new team member should be able to make their first contribution within a week of joining the team. Of course, a week is a general benchmark—some projects might set this timeline at two weeks, while others could aim for just two days. It all depends on the specific context of the project, such as the complexity of the domain, the maturity of the project, and its current state.
What’s crucial is that the timeline remains relatively short. Achieving this goal is only possible when various smaller aspects of the development process are well-optimized and standardized at a high level.
Onboarding and Its Key Components
During the onboarding process, it’s not just the new team member who learns; the team and its leaders also gain valuable insights. Observing how the new person navigates the process can reveal areas where the team or project needs improvement. Breaking this process into smaller components is particularly useful.
Documentation
First and foremost, documentation should exist—but more often than not, I’ve encountered the issue of outdated or incomplete docs. It’s also worth ensuring that a consistent notation, like UML or C4, is used so that every diagram is clear, unambiguous, and each component easily identifiable. Additionally, having deeper context on major project decisions in the form of RFCs (Request for Comments) or ADRs (Architecture Decision Records) can be extremely helpful.
Planning
A new team member should be able to pick up a small, straightforward ticket that allows them to explore the codebase. Regular refinement sessions, with the entire team present, are critical here. Every ticket should include all necessary information, such as clear acceptance criteria, sufficient context, and a detailed description of changes. If a new hire’s first ticket ends up being overly complex simply because there were no smaller tasks available, it might signal an issue with ticket scoping or inaccurate estimations.
Implementation
I firmly believe every team strives to produce the highest-quality code. However, this goal is often hindered by shifting requirements, time pressure or other factors. A new team member can act as an informal auditor (within reason), bringing a fresh perspective to the existing codebase. They may identify areas where for instance design patterns are missing or where a solution requires refactoring. It’s equally important to understand why these issues exist—for instance, is the review process inadequate? Does the team lack domain or technical knowledge? If so, training may be necessary or other forms of filling up the knowledge gaps.
Testing
It’s unreasonable to expect a new team member to fully test all the pathways their changes might impact. To safeguard against regression, the project should include a robust suite of various tests, such as:
- Unit tests
- Integration tests
- End-to-end (E2E) tests
- Smoke tests
- Performance tests
Metrics like test coverage should be monitored, and periodic stress testing should be considered if necessary. Theoretically stress tests may not always be critical for high-traffic services, this can be offset by having excellent observability in place.
Deployment
Releasing changes should be as automated and safe as possible. My personal recommendation is to use proven patterns like canary releases, paired with automated mechanisms to prevent faulty changes from being deployed. Ideally, releases should initially target a limited group of users, and any negative deviations from the norm (e.g., increased error rates, higher latencies, or excessive RAM/CPU usage) should trigger an automatic rollback to the last stable version.
The ultimate goal is to ensure that the team can deploy changes to their services regularly, while new team members feel confident that even if their changes have issues, they won’t have catastrophic consequences for the team or the project.
Onboarding as an source of SLOs
Furthermore having onboarding classified into smaller segments, the team can establish internal Service Level Objectives (SLOs) for each component. For instance, when discussing testing, an example SLO could be maintaining a test coverage level of 90% and having smoke tests and end-to-end (E2E) tests for critical application paths.
For deployments, the team might set an objective for rollback times to the last stable version (e.g., no longer than five minutes). Other examples include limiting the time a ticket spends in the review process to 24 or 36 hours.
These examples are just starting points. The key is for the team to identify which aspects are most critical to their workflow and create meaningful metrics that ensure these elements are consistently prioritized and well-maintained.
Summary
First and foremost, it’s essential to understand that the speed of onboarding should be a natural outcome of a well-functioning team that excels in every aspect of the Software Development Life Cycle (SDLC), rather than a direct goal. The objective isn’t to force someone through onboarding and achieve their first commit within the first week. Instead, it should happen organically.
Onboarding, in its various forms, is an inevitable process in any team. It’s crucial to embrace it, as the efficiency of this process can serve as an incredibly valuable indicator of the team’s and project’s overall health.
