Several of my past companies have had an onboarding convention where a new developer makes a code change that is deployed to production on their first day, or at least their first day after any company-wide onboarding is finished. This is hard to pull off, but in some ways that can be a benefit, and there are a lot of good reasons to do it. Here are a few:

1. Success breeds success: It is impossible to overrate the effect of an early win when starting a new job. As management, if you can give this to a new hire faster than they expect, you are setting an internal narrative of success for this person and giving them confidence.
2. Strengthening team bonds: I like to do this with a buddy system, where an established team member pairs with the new person throughout the entire process. They help them get their development environment set up and figure out how to make the change, answering any questions that come up along the way. The established developer will enjoy the opportunity to share their knowledge and make the team better, and the new person will have formed their first interpersonal bond within the team.
3. Faster learning: For tactile learners who mostly need to learn by doing, you will likely delay their impact a lot if it takes them weeks to see all of the facets of your software development process up close. Not everyone learns like this, but a lot of developers do, and you are helping them to ramp a lot faster if you can give them first-hand experience with the full lifecycle of a change this quickly. They may not grasp everything fully on this first run-through, but they will have a basic foothold into every step of the process that they can build on later.
4. Show that time is of the essence: If you are an early-stage startup (as my companies have generally been), it is important to send a message that time is a valued resource at the company. You may be burning through runway every day, and it is essential that your team see speed of iteration as something to prioritize, so that you can build more value into your product and get as many bites at the apple of finding product-market fit as possible.
5. Forcing functions: This last one is where the difficulty of such a policy becomes its strength. Sure, you could accomplish day-one deploys by just yolo-merging every new hire’s change and hoping for the best, but if that’s your only option then you are likely just going to opt for a slower approach. To make this work, you will need to prioritize maintaining a development environment that is easy to set up, a code base that is legible and well-documented, fast builds, good test coverage, good code review culture, safe deployments at any time, and many other things that you should be prioritizing anyway. you will also need to maintain a small backlog of onboarding-friendly tasks appropriate for different experience and skill levels. These could be as simple as a minor copy change; there is still value in figuring out how to hunt down the change and seeing the SDLC all the way through.

I’ll close by saying that not every company needs to do this, but more should probably consider what it would take for them to be able to. I have felt great about it when I have managed to put teams in a position to be able to have this convention, but every company and team has different needs and goals and I’d imagine this is particularly difficult for teams in highly-regulated sectors. Using similar logic as Charity Majors does in her excellent post Friday Deploy Freezes Are Exactly Like Murdering Puppies, though, I would encourage you to really look at what is keeping you from being able to do this and prioritize solving those problems, whether it’s poor test coverage, slow review cycles, legacy code that no one understands, or any other problem; it will pay off for everyone on the team, not just the new hire on their first day.