How We Efficiently Onboard Engineers at Very Good Ventures

At Very Good Ventures (VGV), our work often involves welcoming engineers into new projects—whether launching a new initiative, expanding a team, or supporting coverage needs. With new assignments starting almost every week, we’ve gained a deep understanding of what it means to step into a tight-knit team with established rhythms and long-held knowledge. We know that without the right structure, even the most talented engineers can feel slowed down by unclear access, siloed information, or complex enterprise environments.

‍

Because we’ve experienced a wide range of onboarding scenarios—both exceptional and less than ideal—we’ve designed a smart, cohesive process that helps teams avoid common pitfalls. Our goal is to make sure engineers feel empowered and set up for success from day one, where new engineers gain momentum quickly, and existing teams stay focused and supported. 

‍

Creating these kinds of smooth transitions starts with understanding the core reasons onboarding can break down—and building a process that proactively addresses them.

‍

The Four Stages of Competence

‍

To understand why weak onboarding experiences happen, it's helpful to consider the Conscious Competence Learning Model by Noel Burch. I first encountered this concept while training baristas nearly a decade ago, and I've since realized its direct applicability to engineers onboarding onto a project.

‍

An engineer typically begins at Unconscious Incompetence when starting a new project. At this stage, they’re unaware of the systems they'll need access to, the location of the codebase, or even its fundamental structure.

‍

As the onboarding process begins, they quickly realize there's a significant amount to learn. This marks the stage of Conscious Incompetence. This phase is often accompanied by discouragement, as contributing to tickets (especially in a complex environment) can feel like a distant goal. During this critical stage, it’s essential that other project members provide ample support.

‍

Over time, the engineer gains a solid grasp of the project and begins to make meaningful contributions. They’ve reached Conscious Competence. While they don't know everything, they can readily find answers to their questions. They understand the steps required to get code changes approved and merged and can reliably execute them.

‍

However, that's not the final stage. After months or even years of working on a project, an engineer attains Unconscious Competence. They possess such an innate understanding of the codebase and systems that they no longer need to consciously think about them. They’ve likely participated in significant changes to the codebase over time, understanding not only its structure but also the underlying rationale. At this point, they experience very little friction in closing tickets and guiding the project to success.

‍

Understanding this model helps us recognize that onboarding isn’t just about sharing credentials or setup steps—it’s about guiding someone through a psychological and technical journey from uncertainty to mastery. By identifying where new engineers are in this lifecycle, teams can tailor their support to be both empathetic and efficient. 

‍

With that context in mind, let’s look at some practical ways to smooth the path and help engineers reach competence faster.

‍

Practical Tips

‍

Here are some tips we've found incredibly helpful for improving the onboarding experience and reducing the time it takes for new engineers to become productive:

‍

1. Leverage Consciously Competent Mentors: Your most effective mentors for onboarding are typically those in the Conscious Competence stage. These individuals are productive but require conscious thought to maintain that productivity. They know the processes to follow and often rely on checklists and notes to remember the steps. These practical solutions are extremely helpful to someone onboarding to the project.
   ‍

Conversely, those who have reached Unconscious Competence often have such a deep understanding of a project that they struggle to recall what it felt like to be new. They may inadvertently omit crucial steps because they perform them without thinking. For example, the experienced developers already have the necessary tools installed in their computers, know all the in-progress refactors, and remember all the tradeoffs that led to the current codebase. This is particularly true if an entire team has been working together on a project for years - it can make it seem like an insurmountable task to bring a new person up to speed.

‍

2. Continuously Improve Onboarding Documentation: The simple Boy Scout saying, "Leave it better than you found it" should guide our approach to onboarding documentation. When onboarding, having information readily available in a README or other documentation is invaluable for answering questions. Yet, no one enjoys taking time out of their busy day to write documentation, especially when the information feels like second nature.
   ‍

At VGV, we have a policy that every person who onboards to a project must contribute something to the onboarding documentation. Eventually, we all encounter obstacles that need resolution. The expectation is that you help the next person by documenting how you overcame that issue.

‍

3. Key Items to Document: When it comes to onboarding documentation, consider including the following:
   
   
   • What does the overall system look like? Which are the key components, who owns them, and how do they interact? Consider including a simple diagram or C4-style overview to show how the system (and teams) fit together.
     ‍
   • What systems require access? This typically includes communication platforms (e.g., Slack), ticket tracking (e.g., Jira), code repositories (e.g., GitHub), design files (e.g., Figma), and knowledge sharing platforms (e.g., Confluence).
     ‍
   • Which API keys are necessary to run the application locally and aren’t checked into the remote repository? Where are these keys securely stored?
     ‍
   • What steps are required before running the application locally? Do Docker services need to be started? Is a build script necessary? Which environments should be run locally?
     ‍
   • What is the established Git workflow? Which branch should be used as a starting point, and which branch should changes be merged into?
     ‍
   • What are the expectations for merging code change requests? Is it necessary to update localizations, add test coverage, or ensure code is free from spelling errors? How can all of this be verified before submitting a change?
     ‍
   • Provide a high-level overview of what each part of the codebase does. Where should an engineer look to find features they’re working on? If the project utilizes subpackages (which is excellent for separating concerns), consider adding comprehensive README files to those packages explaining their functionality in detail.
     ‍
   • Provide an overview of who’s involved with the project, including engineers and support roles. You’ll never be able to document every question imaginable, so sharing who is available to answer questions helps reduce any time wasted bouncing between people.
     
     ‍
4. Integrate Onboarding Documentation with Code Changes: Treat changes that impact onboarding with the same importance as changes to the code itself. If a code change has onboarding implications, such as introducing a new SDK that requires local configuration, don’t accept that code change until the onboarding documentation has been updated accordingly. Additionally, add a to-do item to your pull request/merge request templates requiring developers to consider if their changes necessitate updates to the onboarding documentation. Furthermore, ensure reviewers also consider this aspect during code review. 
   ‍

Finally, as you add new systems and features—especially before calling it 'finished' (since code and details often evolve)—add comments in the code that would help a newcomer understand its high-level purpose, intent, structure, and usage. It’s worth noting that AI tools are extremely helpful at this task. Configure your AI tools to prioritize writing concise yet helpful documentation and make sure AI code review tools are checking that large code changes are documented.
‍
‍

5. Design for Easy Onboarding: The most effective way to avoid an extensive onboarding manual is to make it inherently easy to get started. Utilize IDE features like recommended extensions and launch configurations in Visual Studio Code. Organize your code by feature, co-locating different layers (like state management and views) with easily understandable names. Establish a clear, single vault for API keys and name them simply to ensure clarity regarding what’s needed. Best practices also help a lot with this process, as there are less project-specific practices to learn. Find our best practices and standards at https://engineering.verygood.ventures. 

‍

At VGV, caring about onboarding isn’t optional—it’s a core part of how we deliver successful projects. Every team is responsible for ensuring new engineers ramp up efficiently, because the speed and quality of onboarding directly impact project outcomes. It can’t just be the “new person’s problem.” We measure success not just by delivery metrics but by how quickly new teammates move through the four stages of competence and begin contributing confidently. 
‍

Setting an outcome-driven goal—for example, aiming for new engineers to reach conscious competence within their first week—keeps teams intentional about onboarding and reinforces our belief that great projects start with great beginnings. That’s why we treat onboarding with the same intentionality and respect given to CI/CD, testing, asset management, and other non-code aspects of a project. Just like those “external” systems only prove their worth in moments of need, great onboarding documentation becomes invaluable the moment a new engineer joins, and future teammates will thank you for having done the work ahead of time.

‍