Educating versus Motivating versus Overwhelming versus Suffering 8

[skeletron]

Question:
How do YOU balance educating and motivating a junior without overwhelming them and without making them "suffer" too much? By "suffer" I mean — prevent them from spinning their wheels on a problem so much that they stop caring about the work.

Background:
Recently I've been taking the role of supervising a junior. They have expressed an interest in doing more design work as opposed to strictly drafting duties. So I have passed a few projects on which would allow them to proceed with simple design work. In the process I have identified certain gaps in their knowledge when their questions come flooding back. I've started setting up an electronic library for them to access resources (code books, academic papers, reference books). I also have made my personal books available to them. These resources help me answer relatively elementary theoretical questions that I would like to take the time to answer but can't afford the time everyday without my workload suffering. I've gone so far as scheduling regular meetings with them where I give an hour lesson with a checklist of the necessary design steps.

My worry is that there have been poor habits established in their past. For example, always defaulting to a software solution without the ability to follow through the steps by hand. Another example would be that they will try to debate their way out of running a short calc using specific code clauses (ie. "it's not increased by THAT much so it should still be good" versus actually knowing the numbers). These poor habits show because they are quick to hide when they don't know something and, instead, try to dig into a highly hypothetical theoretical situational discussion about a concept (ie. hyperfocusing on a problem that doesn't exist in the particular design situation).

I'll admit that I wasn't the perfect EIT years ago, but I did recognize the need to know and understand how to get the result and what it means. And I'm definitely not the expert PE, but I've seen and designed enough that I can direct and design with confidence. So...how do you balance educating someone in order to motivate them to excel at their job without overwhelming them in thinking that they are inadequate?

 

[RVAmeche]

Everyone learns differently so you'll likely just have to figure out what's best for your EIT.

1) Regarding the wheel spinning thing, when I first started I'd be given a calc or drafting task, whatever, and told it shouldn't take more than x hours. So I'd work on it and if anything came up that made me think it'd take longer I'd go talk to the PE about it to see what he thought. Also note this was the amount of time expected for a junior level person to figure it out, not the senior level guy who zips through it.
2) It's unfortunate that so many codes and standards are hard to read and follow since they're so important to our work. Eventually coming to an understanding of code requirements and relevant major sections is important, but if the EIT is asking why the design is x, I'd just give a high level overview of why that design was chosen over potential alternatives and how the code lets you make that decision.
3) Reliance on software is a thing. Have the EIT start out by doing whatever calculations by hand/Excel using the standard equations or simplified formulas to get a better base of what kinds of numbers to expect. Once they become more comfortable with the calculations and variables involved, then they can start to work on the software model and be a bit more involved compared to "E = x psi, F = y kips". If there's issues or common pitfalls with the software, talk to them about it and go through it with them.

I preferred it when the senior level guys treated it as an actual training/learning experience answering questions, providing insight, etc, instead of just a "homework review" approach where they said "no, E should've been this. Change it and it's good".

 

[IRstuff]

My worry is that there have been poor habits established in their past.

Certainly a worthy concern. However, it's likely that the "habit" isn't a just habit, per se; they may lack the "knack." I've noticed that there are far too few engineers that can actually internalize the physical reality; data is often just a bunch of numbers that can be tweaked with knobs. The issue is that they can't seem to go beyond the knobs to the physics, or optics, or whatever, and understand what's actually happening when the knobs get turned.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[GeoEnvGuy]

Some things to consider
Share the end vision
Define the tasks
Define the time or level of effort for each task expected
Follow up at regular intervals
Expect the deliverable 30% different and 10% wrong.

 

[tygerdawg]

How "junior" is Junior?

I teach University classes. My observations of the younger generation's behavior has led me to develop the opinion there is a significant lack of the mental skills, tenacity, and curiosity needed to develop an understanding of a complex subject. Not all, but a significant proportion.

I'm not in the business of "bashing Millenials" or anything silly like that because I know they are the future. But like you I see a tendency to seek the fastest answer to get out of doing the hard work. And the answer is submitted without any understanding or concern about sufficiency or accuracy. From where did they learn that? Hmmm: give you one guess. Then when they are challenged on questionable results there is a disturbing tendency to devolve into an excuse machine rather than seek a means of improving their method or skills.

It's troubling to me because I keep realizing that those methods of learning that worked for me back in the 70's & 80's do not apply well anymore to the iPhone and YouTube and Google generation with lower bars and online classes. Perhaps those learning and motivation skills don't plug in as well as they used to. As one Third Year student complained to me when he had to determine the area of a circle and didn't know the formula, "Why should I have to remember something like this when I can look it up on my phone in 10 seconds?" Generational differences.

How to motivate them to higher performance? Well, when you figure it out maybe you could send me a note.

TygerDawg
Blue Technik LLC
Virtuoso Robotics Engineering

http://www.bluetechnik.com

 

[skeletron]

That graph is pretty spot on!

The "junior" is actually a year or two older than me, which is a bit comical. Less design experience (0 versus 10 years) but more education (Masters vs. Bachelors) so it's actually a strange situation when you compare those metrics. I'm slowly learning what works and what doesn't. And the things that work usually work because they require a bit more prep time to setup (kind of like that graph). I guess part of it is also getting my patience aligned so that I don't expect perfection and independence by the 2nd or 3rd iteration...

 

[truckandbus]

For my truly 'new' employees I usually start them off with assignments I already know or can quickly find the solution - tasks that will illustrate their ability to research, to deal with difficult individuals, and to interact with multiple disciplines and departments and if they don't succeed or provide the wrong answer I have it covered. If they can manage those situations I give them some 'fail safe' tasks that are part of a larger project - if the design doesn't work out there is time to recover, no real impact to timing or cost and they get lessons learned experience. After that they get free reign over a small project that i don't really know what the outcome will be. I ask for status updates but I make it clear they are the ones coming up with the solution. Forcing that ownership after building their confidence seems to be effective. I also give them latitude as to how they derive a solution. If it isn't the way I would do it but they produce a satisfactory result we stick with their solution

 

[CWB1]

If you're having to give them more than 30-45 mins/week plus random quick questions then you need to narrow their scope of their work. Start with the work they can do and add a new task every month or two. You want them to master a few tasks at a time for a single role, not waste effort trying to learn everything at once. If you are at a smaller company then you might use this opportunity to review your division of labor, in many cases its unethically poor.

As for hand-calcs, given a specific set of circumstances they are a great way to get a rough approximation for double checking a single sim result. As a sanity check that's great, beyond that not really. Personally, I've been burnt many times by folks running hand-calcs who were focused on a single solution rather than understanding the trends that a quick variable sweep within a sim would've shown. I encourage junior engineers to jump into simulation, albeit with a careful eye to detail, but jump in nonetheless in order to begin understanding these possibilities.

 

[Leftwow]

Junior Engineer here,

First off I'd like to exclaim that I've been told I have a bad attitude. So I'm trying to change that. When I've read these comments, I just wanted to state that these junior engineers don't realize how lucky they are to even have an experienced engineer that wants to teach them. Second off, I've had a discussion with an experienced engineer here at work... He claims there are two types of engineers that graduate; one being the engineer that's genuinely interested in what he's tasked to do and the other being the engineer that got his degree to climb up the ladder and get a pay check every week.

The students I went to school with were mostly the second type. It occurred to me after a professor had offered a wood design class at my university, there were maybe 2 students who were even interested, the rest scoffed. BUT they showed up on time, got their work done and crammed enough the day before to get a B on the tests. The professors didn't know any different. These students go on to pass the PE. Get thrown into a situation where they shouldn't be, and make lots of mistakes.

 

[IRstuff]

At this point, t's almost moot for me; the people that I think I could mentor are all around my age already, if not older ;-)

The younger ones either have the curiosity, but not the math chops, or have neither. Most of the other possible candidates have moved on, and it's been at least 12 years since there were people that could have eventually replaced me. I'm probably needing to retire in about 4 years, given my spouse's desire to do the same, and then do what John Baker's doing, which is traveling the world and sightseeing, etc.

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[jrs_87]

1 educating
2 motivating
3 comfort

Pick two of three.

 

[HamburgerHelper]

My opinion on this is that a lot of this is the result of the employer and the position. Training and insight into a position is what makes the job interesting and more than what it presently is. Very few employers provide training and even fewer provide good training. Most engineering jobs are crank jobs where the goal is to get out as much product as quickly as possible. The employer rarely does much to make the job more fun or interesting. Sending people to conferences is looked at as an expense rather than a tool to keep their employees interested in their work. Software makes it easy for an employer to think that training is not needed or that work experience should not be valued the same. Most or at least a lot of companies don't really have technical tracks. If you really want to work your way up, you have to go into management. There is a growing perception in a lot of places that if I ever need "real expertise" I'll just find an outside consultant. How much blood sweat and tears can you expect a new engineer to put into learning his craft when it is a common perception that he will move into a non-technical managerial or project management role five years in anyways?

I think there is nothing wrong with recent graduates. There are a lot that I don't think love engineering but you'll find a lot of people in any field that don't love their craft. Way too many are afraid to ask a question and look dumb. New engineers should be a little selfish and be trying to gather information and tools for later on in their career. Find an engineer who likes technical material and asks a lot of questions. That engineer is going to be very good with some experience. If you have an engineer that doesn't ask "too many question", they will never learn the why's and will always fall back on "that is how it has always been done" or "that is our standard".

If I was bootstrapping an engineer for my group or firm, I think I would bring them along for lunch or set aside time every friday to just talk shop. Workwise, I would give them project examples for projects that they would be given that would be a little over their head and would force them to ask a lot of questions.



------------------------------------------------------------------------------------------
If you can't explain it to a six year old, you don't understand it yourself.

 

[SandCounter]

The effectiveness of the efforts of any one person ends at 85% of the completed task. Anything after 85% will be changed and is a waste. The changes come from the peanut gallery, new details or findings, commercial or economic changes, or preferences from a supervisor. Further, efforts after 85% become increasingly steep, i.e. wheel-spinning.

The only way to defy this principle is to bring in another person at the 85% point that brings something to the project that the first person does not have. It may be expertise; it may be low-cost time; it may be just a different perspective; or just authority to move things forward. If that second person drives to their 85% point, you've achieved about 98% with far less effort. Put another individual in the mix and their resulting 85% puts the project at about 99.7%. Huge amounts of effort and resources can be saved by people knowing their limitations and knowing when to seek help.

The efforts of each individual should be to drive full speed ahead to 85% as fast as possible, and either pass the work on or force a decision.


I used to count sand. Now I don't count at all.

 

[HamburgerHelper]

SandCounter,

There is no shortage of people that can get anything 85% done or correct. The last 5-10% takes an incredible amount of work and checking.

------------------------------------------------------------------------------------------
If you can't explain it to a six year old, you don't understand it yourself.

 

[glass99]

In terms of setting attitude, I think a personal relationship with a mentor is pretty important. The relationship should have an aspirational quality for the junior, so the mentor needs to conduct themselves with a level of gravitas. You don't want to be the cranky old dude insisting on why computers are stupid. You do want to be the wise older guy that can conjure magic. It also helps a lot if the junior feels like you give a damn about them, and that you are excited about your work.
-> its a lot of work to build a real engineer.

 

[IRstuff]

why computers are stupid

But, they are; otherwise, they'd be doing your job ;-)

TTFN (ta ta for now)
I can do absolutely anything. I'm an expert!

https://www.youtube.com/watch?v=BKorP55Aqvg

faq731-376 forum1529 Entire Forum list

http://www.eng-tips.com/forumlist.cfm

 

[graybeach]

One thing I like to do is to have junior engineers get in the habit of always "scoping" their assignments. By this I mean they take some time to review the information provided and hopefully ask some questions, and then write down a vision of the completed assignment and the process they will use to get there. This can start out very simply, like "I am going to design a beam based on the loading, span and maximum depth I've been given using the AISC code; and, b) prepare a detail for drafting." Over time, I will start asking them to include how long they think it will take, do they have everything needed, what could go wrong, etc.

 

[MrHershey]

For me it varies a lot by individual. Lots of different personalities and learning styles out there. Some love to get lost in the weeds and have trouble getting things done on time or under budget. Their technical knowledge is often quite good but they have trouble efficiently turning that knowledge into designs. Others do the bare minimum to get the task done. Whether it's a lack of knowledge, interest, laziness, distraction, whatever. They'll give the illusion of being efficient but the end product often has a lot of question marks. These two personality types have to be approached differently as the former loves to "suffer" and needs to be reined in, while the latter needs more suffering to develop better.

In general I find it's helpful to give both personalities manageable pieces and lay out a road map similar to what graybeach said. For the former type it helps give them a road map to avoid going too far off course. For the latter it helps give them a road map so they know which road to take.

On the program side, I personally tend to veer into it. Young people are going to heavily rely on programs, nothing you do is changing that. As someone on the older end of what many would consider the young range, I find myself doing it too. Instead of fighting that, try embracing it and digging further into the programs. Most of these programs have technical manuals that walk through the steps in the various design codes they're following. Use the manuals as a backbone for teaching the process and showing that the program isn't a 'black box'. It's performing specific tasks and pulling from specific locations in the code. For me it seems like most of the aversion to hand checks isn't laziness, it's not knowing what to check. The manuals help that by providing a clear design progression and pointing to specific code provisions. Along the way, point out areas where the program is making assumptions (hopefully conservative) and items you commonly run into that the program isn't checking. Along with handchecks, I'd also recommend doing simplified models to explore behavior and better understand what program is and isn't doing.