Ready! Set! Getting New Team Members off to a Good Start.

Often times, a new team member is also a new hire. . .

My friend Peter started working at EvilEmpireSoft on the same Monday that I started at Geekaplex. That Friday, over beers, he told me that he had spent most of his first week waiting for his laptop to show up. When it finally showed up, it had an outdated version of the development environment installed which couldn't compile the code he was supposed to be working on. On top of that, Outlook was misconfigured and wouldn't even think about connecting to the mail server. He spent an afternoon figuring out the configuration only to discover that his email account hadn't been activated yet! "It's as if they were surprised when I showed up for work on Monday. Maybe they forgot that they hired me? I spent the first morning waiting in HR until someone was available to give me paperwork to fill out. After that," he went on, "I spent the afternoon wandering around looking for an empty cube to claim."

I felt bad for Peter, and I was almost embarrassed at how different my first week had gone. My office was just down the hall from my boss's. There was no mistaking that it was mine, as my name was on the plaque next to the door. Inside, I found a shinny new ThinkPad with a docking station and a pair of flat-screen monitors. The drawers in the desk were filled with new pens, pencils, paper, a stapler, and even a box of freshly printed business cards. My boss sat down with me and walked me through my first week, pointing out the various meetings and training sessions that were already on my calendar. There was even a welcome email from the president of the company waiting in my in-box.

"Wow!" Said Peter, "You're like a VIP over there! I feel like most folks don't know I exist, and if they do, they are just hoping that I won't bother them. It really sucks. EvilEmpireSoft seemed so cool and together when I interviewed, but now I'm wondering how they get anything done. They aren't the elite, well-oiled organization that I imagined them to be. I feel like I made a big mistake accepting their offer."

What a big difference attention to detail and a little preparation made. By simply taking the time to provision my office, my boss sent me a strong positive message about the company, and how much they valued me. Additionally, by making sure that I had all the tools I needed to be productive, they let me know that they expected me to be productive. I felt like Geekaplex had it together, and that they would expect me to have it together as well. I felt welcomed and challenged.

Originally posted here:
blog.technicalmanagementinstitute.com/

One has to wonder how hard this problem actually is.

I my experience new people that come on board never have all the skills they will require. That's why it's important for me to run my projects in such a way that people aren't expected to be extremely talented.

That's why tasks like updating design documents and writing documentation are part of our iteration planning and burn-down charts.

A new project coming soon, I wanna try these agile practices :P

Steven, it seems you have balanced the tactical (get the software done this week) with the strategic (and make sure we can continue to do so). But not all teams have done this. When things get tough, some decide it's ok to worry about the future in the future, i.e. we'll catch up on that later.

Sounds risky to me :-) The future doesn't usually ask if you're ready before it arrives, lol.

Where I work, technical policy announcements are sent out via email and never added to a central repository like a wiki. I was told that the wiki is not the place for that type of info.
New guys are screwed until the parts for our mimeograph machine arrive.

Hi there Steven,

The problem I've seen across many projects inside and outside of agile development is most people are thrown onto a project and assumed they'll pick everything up. The best case I've seen is a single day walkthrough where the new person is bombarded with everything in one go.

I wanted to express alternatives that I've found very effective and useful in different circumstances to drastically improve the learning speed of new team members. I agree that lack of skills can a problem and so plan accordingly. I've also seen people with skills not applying it correctly because they lack the context of the entire project. Hopefully these techniques will help build this context faster for them.

Good luck. I'd certainly appreciate finding out how they were useful/not useful for you.

Good Article Patrick. In the team I just built I think I did about all of the tasks above, but not formally. I wish I would have had this before I started! It is good to recognize that building a team is different than running a team and has it’s own set of tasks.

One thing that we did do that was very effective was called 'designing the alliance'. It is a bit 'HR' but really effective. Basically, we agree on 4 things:

Granting Power to the Relationship: Permission to be open in communication, How do we communicate when were ________? How do you like to be communicated to?
My communication style is ________.

The logistics of the relationship: when / where you both work, how best to communicate, what is required (updating JIRA, daily scrums etc.) All the stuff that is expected of you (both ways!) as a team members.

Discovery: What needs to be at the heart of our relationship for it to be effective? What are the obstacles or potential obstacles? What might I do that would really piss you off? (You learn a LOT from that one!)

Future: What are your goals for this project? What types of rewards will we both get? How will we celebrate our successes?

If you get this done at the beginning of the relationship (we write it down and all sign it) it really opens of communication with team members from day one.

Jeff, your "alliance" is interesting. You mention "both" - in a multi-player communication game like a software team, who does this refer to? Thanks.
deb

Nice article, Pat. I couldn't agree more.

The steps you outline for the onboarding process are good ones that are all well laid out. It's important in the early stages of a project to create the documentation/artifacts you'll need to expedite all those steps when they happen later. If you wait, you'll only be distracted with the other things going on in the project and not do as good a job.

An ounce of prevention absolutely beats a pound of cure here.

Can I be on Jeff Bonnes team? Great outline for setting up the rules of engagement. I'm definitely going to steal those ideas.

Pete Johnson
HP.com Chief Architect
Personal blog: blog.nerdguru.net

I'm Alexander Pavlenko, Java Solution Architect. Some days ago, I interviewed a new guy for my project team and he is going to join us next week. I will try this practise and, of course, I will write about my experience.

Thanks

Hi Jeff,

I'm very intrigued about your alliance approach. I will definitely try it out the next situation I get to.

Thanks for sharing.

Hi Deb. In our context, it was the Scrum master and the team members as a start. We also had some Senior developers do it with starting programmers. It could also happen between team members. What I have found is that if it 'starts at the top' the communication between all team members is open, it filters to all the relationships (or at least most!)