March, 2009:

So, you’ve made it through my technical interview, http://benjaminhysell.com/archive/2009/02/the-technical-interview/, you have accepted a position within my company, and even better you are going to be working for me.

I weep for you and your family.

The first six months are the worst.  It’s mostly the hazing, or maybe it is the occasional beatings that will make your time truly unpleasant.

No, no, it’s the hazing.  The hazing is much worst than the beatings.  The beatings are actually not so bad.

First, you’ll have to work on the last 286 computer we have in the office, on a 13-inch monochrome monitor…in MS-DOS 5.0.

Your days will be filled with pain and sorrow, and your nights consumed with thoughts about the next day.  Co-ops who have been working in the office longer than you will walk by and spit in your general direction.  The co-ops will hold rank over you since they have been with the company longer than you, even though you are a full time employee.

Or rather, your first day will be filled with filling out paper work, figuring out your way around the office, and finding the bathrooms.  We’ll get you setup with your new computer and get you familiar with our network policies.  The following six months will be filled with getting up to speed with your new projects, how we work, our techniques for managing people, and team building…the normal humdrum stuff you would expect with any other job.

Really, your first day could go either way.  Join the company on an odd day and co-ops spit on you for six months.  Join on an even day and you fill out paper work and start team building.

With either path, the method in which you conduct yourself for those first six months can have a lasting impact on your career trajectory.  People generate their first impressions about you on day one, however those first impressions take time to cure, and are rather malleable for the first six months.

What I have assembled here in this post are tips on how to conduct yourself with your new team as you work through your first set of technical problems and get familiar with your new line of work.

These tips are not necessarily technical in nature, rather, ideas that you can incorporate into your daily work life, whether you are just starting a new job, or have been with your company years.  I hope that you are already 1. Smart, 2. Gets things done, and 3. Passionate, otherwise you wouldn’t have made it through my interview.  It is my hope now with these tips you can show off these attributes to your co-workers and bosses.

I present to you my list on “How to be a Good Team Member”.

1. Ask, “What can I do to help?”

I’ve been involved in my share of crises, the system is down, the ship date is approaching, the building is on fire…in each one of these situations everything is usually under-control because leadership has taken over and is handling each crisis as it arises.

Or shit has just hit the fan and the system is down, the ship date has past, the building really is on fire, and nobody knows what to do.

When found in the later situations one of the most helpful questions you can ask whoever is in charge is, “What can I do to help?”

You might not be able to do anything, it maybe just that bad.  However if there is anything at all that you can take off the leadership’s plate it can free them up to focus on more pressing matters.

Plus, this simple phrase puts out in the open what hopefully what you were thinking internally.  It lets everyone around you know you are ready to step up and help with the current crisis with whatever knowledge you can bring to the table.

What about the situation where you know you can’t help, the current situation is so far out of your realm of expertise you have nothing to offer?  I say ask anyway, ask how you might be able to help.  You may not know the depth of the particular problems and maybe your skills can be of use.  Worst case, you really can’t help, but you offered and people will remember, “That last system downage was a killer, it was great Johnson offered to help even though it wasn’t his area of the system that was down.”

I’ve been involved in situations where we were rolling out a new system and all hell has broken loose.  Databases are down, routers are misbehaving, and just all around general dysfunction right before we were to officially turn the new system on.  In this crisis it was very helpful to have a team of people asking, “What can we do to help?” vs. a team of people who stood around in silence.  In this situation not everyone on the team could help, but hearing I had people to rely on to help if I found something they could do allowed me focus on the issues at hand.

2. Be willing to keep a sleeping bag in the office

Engineering and software in general doesn’t always work on a 9-5 schedule.  Often times big release dates loom where all hands need to be on deck to help knock out a couple of last minute bugs, or in a support situation something started to blow up at 3 p.m. and we need everyone to pitch-in and solve the issue.

Nothing kills team moral more than someone who isn’t willing to stick out these trouble times and help out.

Hopefully situations like this are very rare, however if you find yourself at a company where this is the operating norm, get out.  Stop reading this post and start on your letter of resignation.  Any company that operates in a continual crisis mode is not a company you want to be apart of.  Hopefully when crisis do arise they are infrequent, or well planned out in advance.

The best way you can contribute to a team is to say, and mean, “I’m not a huge fan of working late, however when push comes to shove I have my sleeping bag in my office.”

It states in an emergency you can be counted on.  This is just as important of asking in the same situation “What can I do to help?”  It shows you are a team player willing to work a little extra now for the team and willing to put in those extra hours to push something to the finish line.

Again, just as above you may never be called upon to fulfill this duty.  However, to a manager it is good to know there are good people that can be counted on in times of crisis.

In the past seven years I’ve asked people to stay late to help sort things out once during a rollout of a new website.  I was lucky to have a team willing to bring in a sleeping bag and ask what they could do to help.  Even though I did not need them to do so they all stepped up, and it was good to know if I had needed them they were there to pitch in.

3. Show you have tried to solve the problem the best you know how before asking for help

I hate sitting down with a developer who has asked for help with an issue and see immediately they haven’t tried to really work the problem before coming to get me.  I’m talking about the obvious attempts to troubleshoot an issue, things I would expect a new hire or a co-op to have picked up while working on a group project while still school.

I liken the situation to taking your car to the mechanic and stating, “My car won’t go anymore”, and having the mechanic turn the key in your car to tell you “Your gas tank is empty, put some gas in your car and it will move again.  That will be $59.95”

The only difference between me and the mechanic is I can’t charge $59.95.  Both of our time and energy have been wasted on an issue that should have been solved before going for help.

Now, if you didn’t know your car needed gas to move…that’s a different story.

I am all about teaching my team things I know…a team member who is willing to learn and expand their skills is a very valuable asset on my team.  However, if we sit down together and I show you something new I hope to see you try it out next time you run into a similar issue.

Did that new technique not quite sink in first time we went over it?  No worries, I am not an ogre…let’s try going over the new method again and explore where I may not have been as clear as I could have been.

I love situations where people ask for help.  They are opportunities for learning and career growth.  If, however, you show up with the same problem having not tried the newly acquired method, I’ll seriously question if you fit into the smart, gets things done, and passionate categories when it comes to your career.

4. Knowing when to ask for help

There is a fine line between asking for help too early, and waiting too long to ask for help.  Knowing your own limits and when to ask for help is a very valuable skill to possess.

Often times when a developer starts working on something they can become so focused they forget to come up for air, and fail to keep the team updated on their status.  Becoming extremely focused on a problem isn’t bad in of itself if you are making progress, but what about those times where you start spinning your wheels on an issue?  You keep trying and trying to work an issue and after four hours you are dizzy.  At this point you start over, maybe attempting to rework the problem with the same techniques you started with four hours ago.

Stop!

You’ve tried everything you know, its time to call in some reinforcements.

You have hit your limit, and by asking for help at this point you create an opportunity to learn something new and advance your skills.  Anyone you ask should be more than willing to help since you have certainly given the problem your best effort.

Failing to ask for help or failing to come up for air is wasteful in terms of time, energy, and the project timeline.  Maybe the problem you are trying to solve wasn’t fully understood by your manager when they assigned it to you, and now you have new information to share…by all means share that information and get clarity on the problem.  You and your manager may learn the problem isn’t worth solving anymore because of how complex it is.  This is a much better outcome than sitting and spinning your wheels for the next four hours as you try to rework the problem again.

These four simple tips will hopefully set you up for success when you start your new job, or help solidify your current job.  What tips have I missed that you would share with a new hire as they join your team?  What have you told young engineers as they have come out of school to join your project?  What have you learned the hard way that you wished someone had told you early in your career?  Share your thoughts in the comments below.