I've been in multiple teams growing from one IC to six or more in six months. Here are recommendations ICs can use to make onboarding easier for newcomers. Onboarding is a very specific kind of lateral mentorship. When onboarding starts, you have a degree of responsibility for the success of your colleagues. They have experience, but they lack the organizational and technical context to do their work. It's an asymmetrical relationship. When onboarding ends, you have a fully equal, symmetrical relationship, with both parties learning and relying on the other. The goal is to help your colleagues become engineers you can depend on. This post talks about strategies you can apply before, during, and after a period of team hypergrowth to make that happen: - Before: Build Understandable Systems, for People and for Agents - During: Write Good Tickets for Newcomers - After: Be Their Peer As a foreword: I've heard people say that onboarding is a disruption from their regular work. I don't think that's true. It implies that your work will return to how it was before. If your team is in hypergrowth, its size, scope, and processes are changing, and your job will be different before, during, and after. Your role and day-to-day tasks will shift. Your responsibility as an engineer and a colleague is to anticipate problems and to make your systems and your work better. ## Before: Build Understandable Systems, for People and for Agents This can sound inactionably general, like "write good code." What I mean is to take time to make your systems understandable to newcomers. This can mean documentation, code organization, naming conventions, interface design, etc... When posed questions, agents can research a codebase and generally provide actionable context about it. Places where agents fail consistently in 2026 merit close attention from their ICs. ### AgentX is DevX An agent always tried to generate infra-as-code configs while creating new services. There was a single-line command to generate them correctly, but the agent didn't know it. Every newcomer tasked with making a service made the same mistake, generating bad configs, since they were using agents and didn't know about the internal tool. The fix was docs. We pointed to the internal tool's docs page in our AGENTS.md. That way, agents knew when it was necessary and why. Newcomers and agents both got the context they needed. Code legibility, tests, and documentation have become both easier and more important post-agent. Agents can only operate on systems that they can understand. [Humans and agents "understand" code differently](/blog/2025/three_way_conversation), but part of the role of an IC is to find effective ways to communicate work for people and for agents. If agents fail consistently, additional guidance is necessary. You can prepare for newcomers by improving the ability of agents to understand and work in your system. ### Find Solutions that Generalize As an example: I [like sequence diagrams](/blog/2026/use_sequence_diagrams) with embedded links to public and private docs, since they are easy to copy-paste, token-thrifty, and render as beautiful diagrams. The same diagrams I use in PR descriptions for architecture changes can be linked or pasted directly in agent prompts for new features, in the service's AGENTS.md, in human-facing service docs, in on-call runbooks, in tickets for newcomers (or for my own coding agents), and shared with external teams that want to understand our data sources, pipelines, and outputs. By making my systems legible to people and agents, they become easier to work on. Mermaid charts are just one technique. The goal is to identify similar techniques that advance a system's "understandability" as a whole for both people and agents. ### Make Understandability a Priority When engineers say agents can't do meaningful work in their codebase, that's a red flag. In 2026, even in enterprise. If agents are consistently making too many mistakes to be useful (especially if they are making the same mistakes), the impact is likely not limited to dev velocity. Newcomers will likely also struggle. Some additional documentation, code restructuring, or other remedy is in order. ## During: Write Good Tickets for Newcomers While onboarding, newcomers are likely to bounce between systems. This experience can be disjointed and fragmentary. Clear tickets give them the opportunity to deliver something concrete. ### Start Small The first ticket should be something that you could deliver in a day. In the extreme, even a ticket with a code pointer requiring a single-line code change can work as a first ticket, to expose your newcomer to the codebase, dev environment, and CI/CD. ### Build Up [Scaffold](https://en.wikipedia.org/wiki/Instructional_scaffolding) the work to get them to their level. Before newcomers join, it can be useful to look at the grid (your company's competency matrix or career ladder expectations) for their level to understand what your company expects of them so that your onboarding is calibrated correctly. ### Example: Creating a new Scheduled Job An example project that I used for a junior newcomer was creating a new job that called an external API. There was a clear business reason for the job that could be expressed in one sentence and was tied to the core mission of the team. The external API's surface was clearly documented, and I provided code pointers and internal documentation for a different service in the same codebase that called it. The first ticket was to just deploy their job using our internal tooling without requiring it do anything. The other tickets were to configure egress, a framing task to decide whether to use one endpoint or another, implementing some simple business logic on the selected endpoint, setting up telemetry for the job, and documenting the job. ### Adjust Tasks and Feedback During Onboarding The grid can be useful for scoping tasks, but it also gives you a checklist of things to give newcomers feedback on. Where do they already excel? Where should they focus their efforts? Can you provide them tasks and structures to demonstrate or even improve competency on domains where they haven't yet shown competency? Give your colleagues clear tasks, with choices to scaffold ownership. Check-in with them about the tickets they are working on. Consider adjusting them if you find that they are poorly-adapted to the newcomer. Some examples: - Sometimes engineers complete tasks much faster than expected. Framing stretch goals with them during the project can allow newcomers to take greater ownership of their work and transition from taking tickets to writing their own. - Two engineers in the same team may come from dramatically different places. Neither are likely to be aware of all of the core concepts or patterns in your stack. Talk with them to understand what missing context they may need (examples: how to manage state in Kafka-based streaming systems, code organization in React libraries, ...). - Live presentations may require more time and attention for some than others. Examples: newcomers unaccustomed to working in your office's primary language, people with speech disabilities, people with autism, etc... Something that works for one person may not work for another. "Overdocumenting" things like presentation formats/best practices for everyone can set expectations and reduce stress, giving newcomers the best chance to succeed and raising the org's bar for presentation quality. People stay in places where they are valued for their strengths and can develop their skills. The marginal effort to personalize an engineer's onboarding tasks is worth it. ### Adjust with the Rest of the Team How are other people on the team handling the growth? Are there newcomers who you don't work with, but can observe as they do their tickets? Are there other team members adjusting to newcomers? Checking in is nice. It also provides an opportunity for you to learn from your colleagues and identify which of your strategies work well and which don't. Part of it is the emotional context. Are they frustrated? Bored? Stressed? You may not be responsible for the emotions of your colleagues, but their feelings impact their work and provide you useful information. And if there are quick wins to facilitate their work, great! Another part is the content. What is hard for your colleagues? What is easy? What can you learn from this? Specific domains may have specific complexities. ## After: Be Their Peer Lateral mentorship is all about reinforcing equal relationships and mutual growth. When an IC has finished their onboarding, the "lateral" part of lateral mentorship kicks in. You need to rely on them as the expert for their work in the same way they rely on you for yours, and make sure that others on the team do the same. Concretely, this means changing your behavior: - Delegate ownership of a subsystem or domain to them. They own it, not you. - Defer to their judgment in code reviews on their area. - Stop framing their tickets — let them scope and write their own. - Solicit their feedback on your work (code, arch, vision, strategy). - Communicate their expertise to external parties. Your team needs them to have visibility on their work. - Celebrate their competencies. Tell them (and your manager) about the specifics when they demonstrate management competency, start solving architectural problems, or take on [glue work](https://www.noidea.dog/glue). Team hypergrowth is usually followed by a period of flat headcount and increasing team output as the team finds its new groove. Look at your colleagues. They aren't newcomers anymore. What can you learn from them? How can you work together? How has your work changed since before hypergrowth, and what have you learned?