Joining a development team: picking up the necessary behaviors

It’s normal that when we first enter a company dedicated to the design and development of custom software,we want to jump into a project and start delivering value, being productive.

But how can we transition smoothly from a recently graduated student into the newest team member that the team was looking for? Benefitting from an efficient employee onboarding program is what made the difference for me.

Acknowledging the challenge and acting accordingly

Joining a new software design and development team means facing unknown situations and getting used to tons of things, from jargon to speed.

• The level of requirements. Joining a software boutique is a challenge. It’s not easy to live up to the expectations and standards! Making the web or mobile application just work is not enough.

• The speed and deadlines of a live product. Some code can’t wait or break. Keeping up with the team’s rhythm right from the start can wear some out.

• The Scrum methodology: planning, dailies, demos, retros…

• The team-client relation: Forgetting about the scary character to start considering the client as part of the team. And as a reasonable person that is able to understand the concepts of bugs or priorities if given the proper context!

All these changes can be intimidating to the uninitiated. Even if the team is amazingly supportive and let’s you know you can rely on them (it will be like that, don’t worry!), it is stressful.

Being part of an onboarding program means that these challenges have been identified by others. It goes from being a personal difficulty to overcome, to just the regular process all developers go through.

Getting started in a secure and friendly environment

This is why I was so glad, when I joined NaN, to go through an intensive onboarding process designed to get used to these changes in a controlled environment.

I shared the experience with a co-worker who wrote about the technical challenge that we overcame: Joining a development team, the story of a journey. The challenge of getting up to speed on technologies and methodologies.

Basically, we developed a web application that could remind some of Twitter. And we used it as a playground to get used to the technologies, methodologies and to find our place in the team

By directly handling and experiencing project-like situations and making mistakes, we were going to learn how to deal with panic attacks, difficult client-developer interactions, and other challenging situations that are part of a developer’s life. If you’re a new developer yourself, no panic. We’ve gone through this, and it does become easier!

And that’s what the onboarding is for: to learn and make mistakes in a safe place, without destroying the company or driving our colleagues crazy!

Being supported by a referent, a pair and a welcoming team

We had a referent that was in charge of guiding us from Day one until the end of the onboarding phase. It made a real difference as it provided us with a clear view of what was expected of us and saved us the discomfort of having to constantly interrupt one of our pairs. Also, referents work as a perfect icebreaker to facilitate integration with the rest of the office if needed.

In fact, in NaN, being a referent for new team members is considered an assignation, just like any other project in the company. And I believe it is key to its success.

My referent was sitting right next to me, making it easy and fluid. No one wants to cross the entire office to ask a question of dubious complexity! It doesn’t mean we couldn’t consult with others. I’d like to emphasize the willingness of all co-workers to insist on their availability to help. During the onboarding process or afterwards. No matter how much one supposes it or not, it never hurts us that they point it out. The more often, the better!

One of the other amazing ideas of the onboarding process, is to have our future team members take a great part in it. In my experience, not only did it help us to build a bond of trust and security with our future team partners, it was also great to get to know how they work, how they handle and solve problems. If you have the chance to go through this, you’ll see they give you tips for the most common problems in their (and your future) project. You wouldn’t know what a blessing it is when later on, you come across a problem in the real project and think: “I had the same problem before, I got this!”

It also gives you that vision that sharing knowledge is part of the DNA of all good team players.

Getting up to speed on the use of agile methodologies

For sure we have heard of Scrum once or twice during college, but having some theoretical knowledge of it is definitely not the same as breathing it day after day. And not as an option or a nice-to-have requirement.

During the onboarding process, just like in any software development project afterwards, you live by the Agile rules! You have all these different meetings that you have to attend: dailies, plannings, retros and demos.

One of the most important lesson I learned, trust me, is that you have to take your time before every meeting to be extremely prepared. Sounds obvious, right? Well, I never realized it as strongly as when I was faced with presenting a demo I had not prepared.

Same thing for dailies. It quickly becomes a very natural habit, but for the first ones, it is not a bad idea to take 10-15 minutes to write down what you’ll expose to the rest of our team. Just so that you can keep it short, simple, and not forget half of the things you’ve done!

Another lesson we learned is that it is both hard and important to estimate tasks, and that unexpected complications occur anyways.

It requires calm to handle all the tasks we need to accomplish during the sprint. Sometimes we couldn’t meet the objective that we had set, most of the time because of inaccurate estimations. Not because of lack of work or mistakes. Mostly because of unexpected complications that we couldn’t imagine when we planned our sprint. But don’t worry, you learn and get a lot of experience with time.

Remember, we are talking about an onboarding process, so we’re here to learn, and that necessarily includes making mistakes every now and then. Estimating is a tough part of the methodology, and the only way to get better at it is to start doing it for real!

Going through a targeted technical ramp up

At this point we have talked about starting to work with new team-mates, learning the methodologies and jumping into a new project. But we are missing something here, right ? Because we are developers, we can’t real do without the tech part!

So, what types of technologies should I be able to use? Do I have the right basics? Do I need to learn something new or improve the knowledge I currently have?

That is luckily something that NaN had thought through. We spent the first two weeks doing some workshops that helped us to get the basic knowledge we needed. That included programming languages, database handling, versioning control system and clean code among others. And after that we had these three amazing weeks where we developed our pet project “Twotter”, that I mentioned before.

Read Julieta’s story, where she describes our journey, getting up to speed on technologies by developing Twotter.

In addition to all the technical knowledge we acquired, something funny to mention is that one of the best lessons we got is that we needed to master our Google Searching technique! Although we are considered great problem solvers and very original working things out, we don’t have the answer to all the problems. To succeed in this profession, we need to learn how to search efficiently!

When we have a project to repair, a ticket to fix, a deadline to reach and we don’t have time to study, we must find a solution in order to deliver on time! This doesn’t mean that we should copy and paste the first solution we find in stackoverflow. Our solution has to be efficient, scalable, clean and understandable. So mix that searching skill with some clean programming and remember that asking a partner to take a look at your solution before pushing your code is a also a great idea!

“It was tough but I’d do it again”

To sum this up, this onboarding program was intense! The pet project wasn’t as simple as it sounds like. It was full of difficult tasks, drastic changes, demanding and retailed clients, among other difficulties.

But it was worth it. The idea of the playground is to help make the insertion in a new project more fluid and safer. At the same time, it had to be in a kind of challenging and slightly stressful environment in order to get you ready for the worst case scenario, because trust me… difficulties will show up in real life too!

So the best thing in this process, is that you can make lots of mistakes and say ” Thank god we screwed it now and not in front of the client! “.