Leave a comment

Dealing with Experienced Coworkers and Learning From Them

It doesn’t matter if this is your first job or your third, you will have the opportunity, and challenge, of working with a broad range of individuals.

As an early engineer working on building your credibility and proficiency, perhaps the most daunting group of people are the experienced coworkers.

Working with Experienced Coworkers

The experienced coworkers

I am not talking about the guy with only a year left before retirement and just coasting, I’m talking about the engineer who is the expert in her field and has ten patents and nine papers to her name.

Perhaps every time you bring up an idea they have 10 reasons to shoot it down. Or they can seemingly walk up to your computer and instantly point out a critical mistake.

After a few of these incidents, you quickly learn to avoid them or get an anxiety attack just by knowing they are going to be in the same meeting.

The difference of years

Why are so many early engineers intimidated or even threatened by senior engineers?

When you look at the differences between the two groups the cause for potential conflict becomes more apparent. While the list below is general to the extreme, I think you could relate to a few of the differences.

Early Engineer Senior Engineer
Fresh from school and eager to go, but little to no experience Decades of experience
Excited to try the hot new things from school but have never used the alternatives Comfortable and knowledgeable with what they have been using
Naïve and optimistic Perhaps a bit jaded and cynical
Used to flitting from one thing to the next (Myspace, Facebook, Twitter, Snapchat…) Learned that diligence and follow through earn respect

Guess what, just as the list above can be causes of conflict, they are also the same reasons that can accelerate your growth as an engineer and professional.

Think about it, that guy who always insists on a certain format could probably list a dozen good reasons if you only bothered to ask why. And the gal that always seems to know about every technical aspect of the project, well maybe you could ask her how she came to master it.

Ok, you may say, but you don’t know my co-worker, he is impossible to ask anything – when I do, he just makes me feel like an idiot!

Been there, and no, it isn’t a good feeling.

It is difficult to try to ask for help only to be made the fool, but a simple difference in perspective is all it could take to overcome your differences.

An exercise of perspective

In my first career job, I had a project to automate some test equipment at our CM to verify the boards were built correctly.

As an aspiring engineer just out of school, I was working hard to get the project done, but holding me up was Jack (clearly not his real name), an engineer with 30 years of hard experience.

The issue all hinged around my wanting to use USB or Ethernet to communicate with the lab equipment – you know modern day technology. Jack continued to insist that this new fangled tech was unreliable and that GPIB was the only way to go.

By Alkamid (Own work) [CC BY-SA 3.0], via Wikimedia Commons

By Alkamid (Own work) [CC BY-SA 3.0], via Wikimedia Commons

Decades-old protocols, very expensive cables, and bloated software interfaces. All sorts of reasons to not use GPIB.

Whenever I tried to ask Jack why he insisted on this protocol, he simply answers that this is how it had always been done, and if it worked for the Military, it could work for us.

I was in a difficult situation. I was trying to prove myself as a competent engineer and believed that the newer protocol could save the company time and money. I was at odds with Jack’s senior opinion.

What is going on here? Was Jack really being a set-in-stone Luddite?

Doubtful. More likely he had been using the old protocol for so many years that he was intimately knowledgeable about the benefits and pitfalls that it contained and had a hundred ways to avoid those pitfalls.

The new protocol was still hot off the presses (relatively speaking), and while it may have looked like a great new thing, Jack  had enough experience to know that looks could be very misleading.

Help them to help you

Think about my situation, I was trying to do what I thought was the best solution and felt that Jack was holding me back.

Humor me for a moment.

Let’s change the perspective to Jack, in his years of working he had probably seen a number of new things come and go, each costing the company an untold number of dollars and hours, and yet his go-to standard was still holding steady. So, when yet another new thing was being presented, he was sure of where it will end up.

So where does that leave us?

The five whys

After trying and seeing many possible solutions, my suggestion is this: ask why.

Not in that childish tone that grated on your mother’s nerves. But really ask why he has this opinion.

Show Jack that you want to learn and the conversation may turn a whole different direction. Most people love to share their expert knowledge, and if it is on an eager ear, all the better.

Once you have Jack talking about why he trusts the tried and true method, keep probing deeper into the details – why is it more secure? Why does that make it simple to maintain? Why do all the CMs use it?

This is a method I learned from Eric Ries where discusses this idea in his book “The Lean Startup”. He uses the Five Whys to diagnose bugs in his software project or customer complaints. His point was that if you keep probing into a problem, or an opinion, you can move past the blame game and uncover some surprising results.

Back in our example, if I had sat down with Jack and asked my whys, I may have learned a good deal about the ‘old’ protocol that made it a great candidate for a number of non-apparent reason.

Alternatively, as the discussion went on, I may have learned that Jack trusted the GPIB protocol because an established company built and maintained it, whereas all the open source standards he’s seen have backfired for lack of unified support.

I could have just gleaned a priceless gift: a tiny piece of Jack’s years of learning and personal experience.

That does not mean I would need to give up my proposal. Indeed, I may have just found a number of reasons why Jack would get excited about it now that I know what’s important to him.

Let’s say I found a USB driver for Agilent oscilloscopes that were written and supported by them.

  • Supported by an established company, check.
  • Provides a secure channel, check.
  • Proven examples of maintainability, check.

If I had spent the time to figure out Jack’s whys it might have saved numerous arguments and painful hours attempting to get NI’s VISA drivers to actually run.

Your take away

So what can you take away from all of this?

First and foremost: remember to be open minded – yep the same thing you wish the ‘older’ crew would be. This is not to say that they are right, but if you can stay open-minded to their opinion and concerns, you might be able to create a better solution than either of you had thought of.

Ask the Five Whys. Following up to being open minded, try to dig into why this experienced coworker has this opinion or choice made. The Five Whys is meant to dig past the surface level questions and truly understand the motivations.

And finally, take advantage of the experience and thoughts these seasoned engineers have. Think of how many projects they have worked on and how many decisions they have had to make over the years. Realize that they are where they are because of this experience. And no matter the gruff exterior, if you pay attention you might be able to get a head start in your career.

Your Thoughts?

Hit up the comments below if you have had some of these experiences or think I am way off base. We are here to learn from each other, so add your voice below.