Hi, I’m New Here

Share on Facebook0Tweet about this on TwitterShare on Google+0Share on LinkedIn0Email this to someone

So, this is something that a lot of you might be familiar with. You start a new job, or a project with a new team. And basically, while you might have some previous similar experiences, it turns out that you need to learn a lot of things from scratch. One thing is for certain — you can’t avoid this. There’ll always be a situation where you’re the new guy or girl.

What does this mean in practice?

You won’t know much about the project you’re joining. Some things will be common for your line of work, of course. But huge chunks of the project you’re getting on will be new to you. While things like the specs or requirements should be documented and therefore reasonably easy to get a grip on, not everything will be.

You won’t know the unwritten rules of the work. Overall, there are a ton of things happening off the official record that have a big impact on how the project is structured, ran, or developed. These are things you’ll have to learn, sometimes painfully, as you go along. It helps to have an angel on the team who will show you the ropes and give you a head’s up about the tougher parts.

You won’t have the historical background of what has gone on before. The current state of the project and the team is a function of what has happened previously, of decisions that had been made before you showed up in the picture. This wouldn’t be a problem if not for the fact that more often than not, past decisions will inform and impact future decisions — human beings are wired that way.

You won’t know the team.
They’ll be new faces, and it will take time for you to get acquainted with them. It will take you even more time to get to know them well.

You won’t be immediately familiar with the requirements and the budget. These can seem like an extension of the first point I’ve made, but they are crucial details. It’s in your best interest to get totally clear on these two things as soon as possible.

Instead, you will:

  • have new ideas,
  • see opportunities for change,
  • reopen closed issues and repeat questions someone’s asked before.

Will all of your new ideas and questions be good? Probably not. Will some of them repeat what had been done and/or solved before? Probably. Does that mean you should not ask them? Hell no.
There are cases where going back to old issues is what gets them solved.

How does that transfer to real life? Well, here are some of the possible outcomes when a newbie asks a question.

It has already been asked: in that case, you should be able to find out the answer and the reasoning behind it. On one hand, it can make the team reexamine what they already know, and maybe decide that answer should be changed. But even if that doesn’t happen, the bottom line, minimum result will be that you’ll know why a certain choice has been made — and that will make your understanding of the job fuller.

It hasn’t been asked before: if people who hear it look at each other in surprise, it means you nailed something that hasn’t occurred to them, but is vital to the project. They can love you or hate you for it, but you’ve just contributed to making the project better, by the virtue of having fresh eyes.

Those fresh eyes mean you’ll have a new perspective. This can result in good ideas that no one on the team thought of before, or it can let you approach an existing problem from a new angle and solve it.
It can even mean that you’ll find problems no one has realized the project would have before they bite you in the ass.

The fact that the team will have to bring you up to speed on all the aspects of the project will mean that they will be more involved and will make them re-contextualize what they already know.
And since you’re joining fresh, you’re likely to invest more energy in the project.

There is a chance that bringing on a new person will make the project’s timeline shift. This is true both when it’s a new person on the development team and when there’s a new person on the client side (that one can be even worse). Again, this is a result of the newbie needing time to catch up on things. It’s not always the case, but it can happen, so it’s good to account for that — if you’re the newbie, try to learn quickly; if you’re the lead on the team with a newbie, you should know that things may slide and make sure you have room to maneuver.

Most of those things are hard, if not impossible to quantify. And in a lot of cases, your job as the new guy or girl won’t be to upend everything with your fresh outlook and new batteries. You won’t need to be the revolutionary, you’ll need to be a learner and a contributor.

But the fact remains that you’ve been brought on to that project for a reason. That people think your skill set will add value to it. So what are you waiting for? Go and knock it out of the park!

Originally published on Underovsky.