How to pick a starter project that'll make someone quit

and how to do the opposite

Ever had “hiring manager’s remorse”? It’s where you regret hiring someone immediately after they start. It could be that you don’t like their face, or just want to see the world burn. Worse, they might have mentioned they like jazz. Whatever the reason, this post is here to help you make them quit on their own by picking the worst starter project for them.

Don’t wait until they’ve settled in

They didn’t get a monitor yet? The PM haven’t gotten around to showing them the product your team is working on? Their badge doesn’t work and they have to ask for teammates to walk them to the bathroom? This is the perfect time to sit them down and explain all the details of the new project. Is there some component that they haven’t ramped up on yet? Save time by not explaining it to them just yet - they’ll get to piece it all together themselves when the project is done.

Pick something big

This is essential. Make sure the project involves as many components as possible. Ideally, it should take the most senior person at least 2-3 months to get done. Picking a big project makes sure they don’t get any small wins or feel good about themselves. If they manage to break the project down into smaller parts, you need to make sure they understand you only care about the end goal, and that you’re worried they are “wasting time on project management” when they should be working!

If someone objects to your pick of project, just tell them you want the new person to feel “a sense of ownership”.

Let them own whatever the person they’re replacing owned

This increases the odds that the project is not fun and that no one on the team really knows what’s going on.

Pick something controversial

If at all possible, pick a project that some people object to. Maybe it’s the technical direction; maybe the PM and the designer don’t agree on the UX; maybe some people just think users are going to hate this.

If you manage to find a controversial project like this - don’t tell them! But do make sure they interact with whoever objects to the project. Bonus points: if the objector is a team member, let them be the mentor.

Let them gather requirements

Make sure to only select an ambiguous project that doesn’t have a known set of requirements. Describe the project with as little details as possible and send them away to figure out the rest on their own.

Add some cross-team collaboration

Choose a project that involves as many other teams as possible. Here’s a possible list of cross-team collaborations:

Let them introduce a new technology to the team

We are going for the sweet spot of both not understanding the existing tools everyone on the team uses every day as well as being the only person on the team familiar with the new technology.

Require a bunch of non-coding activities

Don’t let them compartmentalize! Make sure they have to do anything and everything:

Ensure the project is blocking other people

The project shouldn’t just be hard on its own. We want the new person’s negative emotions to work against them. We do this by adding stress and low self-esteem. Let them know other people depend on them. Bonus points: commit to a strict schedule on their behalf while they’re in the room. In most cases, they’ll just freeze and accept whatever you said. When they complain the deadline is too tight - just remind them that they could have said something at the time!

Pick the busiest teammate as their mentor

Make sure that whoever’s helping them has a lot going on. They should have plenty of meetings and perhaps an irregular schedule. Maybe they work remotely or come in at 05:00 AM to beat traffic. Bonus points: pick someone who’s about to go on leave for a while.

Defer any request for help by at least two working days

Most new people take too long to figure stuff out on their own before asking for help. This means that if you leave them hanging when they’ve already asked for help, you’re making sure that they cannot accomplish anything while they wait. This delays the project, causing stress. But it also cultivates a general feeling of helplessness and low self-worth. Remember: you reap what you sow, so sow some misery!

Set up frequent sync meetings with some higher-ups

Sync meetings can be a great tool to advance a project when used properly - so don’t use them properly! Start scheduling them as early into the project as possible and include as many people as possible. Have higher-ups expect rapid progress and let them know who’s responsible. The rule-of-thumb here is that every sync meeting should make the new person feel like a failure and a disappointment. Let them know you expect them to present something for the meeting - that way, you make sure that they waste their time preparing for the meeting instead of moving the project forward.

How to pick a starter project that’ll make someone stay

Ah, this is embarrassing. You thought they said they liked jazz, but they actually clarified that they like to hate jazz. And their face is growing on you. Hmmm. Maybe we should pick the best project instead, okay?

Starter tasks, not starter project

People underestimate how hard it is to make a single change to their codebase. You’re thinking about lines of code, but it’s so much more than that. What does your team call the action of making a change to your codebase? Submitting a diff, pushing a commit, sending a merge request? Every team does it differently enough that we don’t even use the same terms. Every team has different source control, issue tracker, ticket handler, command line tools, etc. It might be second nature to you, but starter tasks are supposed to help ease a new person into this. This shouldn’t be a sink-or-swim situation.

Start trivially small. No, smaller than that. Even smaller. A little bit smaller…. great! Let someone fix a typo. Let them fix some coding convention on that one module you haven’t gotten around to lately. Let them add their name to the project’s CONTRIBUTORS file. It should be something that is absolutely not a challenge. Figuring out the development flow is challenge enough.

Then, work your way up in small increments. Let them fix a small bug. You should generally know how the solution is going to look like before you assign it to them. Starter tasks shouldn’t break new grounds for you. Let them add a test for that one bug. Let them figure out how to run tests, how to make sure the continuous build caught their change. Let them track it to production. Don’t rush it.

Small tasks provide a lot of easy wins, but they also function as a small tour of your code base. The new person will get to touch a little bit of everything. They’ll start to recognize component names, associate a specific technology and “look” for each of them, figure out where their code is stored in your source control. They’ll have some sense of what you do and how you do it.

Let them work on the core business, the bread-and-butter for your team

Every team has something they are optimized to do more of, the bread-and-butter. A team that works on a payment platform might consider “adding a new payment provider” as their bread-and-butter. A team that works on a to-do app might be optimized to add new task properties and filter capabilities. What is not bread-and-butter is for a free to-do app team to implement payments or for a payment system to add cool avatar selection for users.

Let them do whatever it is your team does best and frequently. This will mean that everything they learn while doing the project is useful, that the skills are transferrable to future projects. It also means that everyone on the team can help them, so they’ll never get stuck waiting for a specific person.

Tasks should be as self-contained as possible

Ideally, the new person should only need to talk to people from the core team to complete starter tasks. Sure, if a task is small and well-defined, it’s not a huge deal if we need to run it by the PM before pushing it. But allowing new hires to feel a little more sure of themselves before starting to collaborate with other functions will make those interactions much more positive for them.

Self-contained also means that there are no complex cross-task dependencies. They shouldn’t rely on someone else’s diff that they’re “just about to submit in 2-3, maybe 15 days” nor should anyone else depend on their change. There’s no point in introducing more stress. They’ve just started a new job, they’re stressed enough as it is (and the stress will come later, for sure).

Learn from past mistakes

Ask folks on the team about their onboarding experience. Ask for help from the last person who joined the team, not the most senior. The newest member probably has better recollection of the experience. They probably have a better sense of which component maintained by the team are hard to grasp (and should be avoided) and which tools are essential to cover during the onboarding.

Pick a mentor, but make sure everyone on the team is approachable

The best developer on the team isn’t always the best person to mentor a new hire. Pick someone who likes to teach and can be available for the new hire. They should probably clear the first few days of the new hire in the office, if they usually have a lot of meetings going on.

However, a single person is not enough. They can be busy, sick or on vacation. The mentor and the new hire might just not have chemistry and find it awkward to talk to one another. Make sure that everyone on the team is approachable, and that the new person feels comfortable asking for help. You can facilitate this by:

Proactively offer help

As I mentioned above, most new people take too long to figure stuff out on their own before asking for help. Preempt this by proactively offering help. However, this should be done with caution, as it can be stressful, too. Offering help might imply that you think they’re late and that you expected to see some progress by now. Let them know that you’re there if they need you, without pressuring them.

When you help them out (whether proactively or not), try not to overwhelm them. Many (mostly senior) engineers tend to answer questions with a flood of intricate detail and long theatrical renditions of how the current situation came about (“It is the tale of a time long ago, when source control was but a rich man’s game…”). Tell them what they have to know, and ask them if they want to dig deeper. Or let them finish the (small) task first, and then give some more context, when they have hands-on experience of what that component does, exactly.

I would love it if you could share your starter project experiences in the comment section below. What horrible choices ruin someone’s experience in a new job? How did your awesome manager make your onboarding easy and fun?

Discuss this post at the comment section below.
Follow me on Twitter and Facebook
Thanks to Yonatan Nakar, Ram Rachum, Haim Daniel, Hannan Aharonov, Yosef Twaik, Sion Schori and Inbal Parvari for reading drafts of this.

Similar Posts

See All Posts