We don’t have a lot of rules for the team at Crowdcast, but I do have one rule for engineers:
Ship production code on Day 1
This rule is surprisingly effective at cutting through the bullshit of on-boarding by forcing a new hire to quickly integrate with the team. Otherwise, a new engineer’s first couple of days on the job sound like this:
“It took me a little longer than expected to set up my environment. The documentation was out of date, so that was a blocker.”
“I have never used <library that your team uses> before, so I spent some time reading the documentation for that.”
“I ‘got familiar’ with the code base/data model. It took a little longer than expected.”
This reflects a lack of focus and direction, and both new hires and their managers are at fault. But it’s lazy and what I call on-boarding bullshit. Here are three reasons why these excuses are a waste of time on Day 1:
1. You’re spinning your wheels. If it’s taking too long to set up your environment, ask for help. If you’re blocked, then speak up and get unblocked when something isn’t working exactly like you were told it was going to.
2. Aimlessly reading documentation is useless. Reading documentation is always more effective when you’re applying the reading to a tangible example, like the project in front of you. This will be more valuable later on, but on Day 1 it is a waste of time.
3. Same for reading code. “Getting familiar” with the code base or data model isn’t of much use in the abstract. You’re going to learn much faster and much more effectively within the context of an actual project.
We realized that we could be doing more as leaders to help new engineers come on board more efficiently. Our policy to ship code on Day 1 is not meant as a scare tactic or to act like some kind of hard ass. The task is often a simple, one-line fix (a misaligned UI element, change an error message, fix an edge case bug). And we’ve found this is the most effective way to make sure a new engineer gets started at the right pace. Here are four benefits we’ve observed:
1. No more BS/time-wasting excuses (listed above). These are significantly reduced, if not eliminated entirely.
2. It sets the tone that our team cares about results. We remind the new engineer that shipping code doesn’t mean “get it working in dev” or “put in a pull request,” just code running on production for all users — so it’s not a super-stressful experience. But the new engineer does understand the importance of seeing this first task through and making sure it gets all the way through to release.
3. It reduces workflow issues. Coding on Day 1 ensures all the key pieces of our team’s workflow are quickly ironed out and new engineers have a deeper understanding of our team’s end-to-end workflow (access to Trello, assigning tickets, branching on Github, pull requests, code review).
4. It holds leadership accountable. When the goal is to make sure a new engineer ships code on Day 1, managers and leadership have to hold up their end of the bargain by making sure the new engineer stays unblocked and has everything they need to complete their first task.
The feedback from new engineers have been positive, and we’ve found our Day 1 policy to be a good test of enthusiasm. I believe new engineers (the good ones anyway) should feel energized by shipping code on their first day and excited about being on a team that shows results. I want them end their first day on the job feeling invigorated after completing this task and be hungry for more.
If it goes well on Day 1, then we build on that enthusiasm to get engineers more fully integrated and take on bigger projects.
What do your new engineers do on Day 1? Respond here or tell me on Twitter.
