Educating versus Motivating versus Overwhelming versus Suffering
Educating versus Motivating versus Overwhelming versus Suffering
(OP)
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?
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?
RE: Educating versus Motivating versus Overwhelming versus Suffering
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".
RE: Educating versus Motivating versus Overwhelming versus Suffering
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: Eng-Tips.com Forum Policies forum1529: Translation Assistance for Engineers Entire Forum list http://www.eng-tips.com/forumlist.cfm
RE: Educating versus Motivating versus Overwhelming versus Suffering
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.
RE: Educating versus Motivating versus Overwhelming versus Suffering
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
www.bluetechnik.com
RE: Educating versus Motivating versus Overwhelming versus Suffering
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...
RE: Educating versus Motivating versus Overwhelming versus Suffering
RE: Educating versus Motivating versus Overwhelming versus Suffering
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.
RE: Educating versus Motivating versus Overwhelming versus Suffering
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.
RE: Educating versus Motivating versus Overwhelming versus Suffering
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: Eng-Tips.com Forum Policies forum1529: Translation Assistance for Engineers Entire Forum list http://www.eng-tips.com/forumlist.cfm
RE: Educating versus Motivating versus Overwhelming versus Suffering
2 motivating
3 comfort
Pick two of three.
RE: Educating versus Motivating versus Overwhelming versus Suffering
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.
RE: Educating versus Motivating versus Overwhelming versus Suffering
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.
RE: Educating versus Motivating versus Overwhelming versus Suffering
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.
RE: Educating versus Motivating versus Overwhelming versus Suffering
-> its a lot of work to build a real engineer.
RE: Educating versus Motivating versus Overwhelming versus Suffering
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: Eng-Tips.com Forum Policies forum1529: Translation Assistance for Engineers Entire Forum list http://www.eng-tips.com/forumlist.cfm
RE: Educating versus Motivating versus Overwhelming versus Suffering
RE: Educating versus Motivating versus Overwhelming versus Suffering
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.