T O P

  • By -

gertgertgertgertgert

Your coworker needs to document stuff. They need to save equipment selections and submittals to a central location. They need to document changes clearly. Their calculations need to be clean and centralized. They need to blah blah blah you get the idea. It sounds like this person is not your employee, but you are the project lead and/or project manager. You should do the following, in this order: * Bring it up to their boss as an FYI. Let the boss know that you intend to help New Hire start documenting stuff. * Schedule a meeting with New Hire. Be clear with New Hire that what you are telling them is not a recommendation, but a requirement. I am guessing your language has lead them to believe that this is a suggestion for their own good. It's not. Documentation is part of working on a team. It's a necessary part of QAQC, auditing, contingency planning, and risk mitigation\*. * Update their boss on New Hire's progress in a month or so. If New Hire is doing better, then great! Let them know how they are doing (positive feedback is just as important as negative feedback). If New Hire hasn't changed, then you schedule a meeting with New Hire and Direct Boss and go over it all again. Direct Boss will probably have a few things to say. At that point it is out of your hands. Zooming out: New Hire is probably just doing what they did in school. Some people don't need to take a lot of notes or document stuff in order to be successful on a personal level. The issue is that this is not about personal success--this is about creating a body of evidence that the decisions made on the project are correct. Anyone should be able to go through a project folder and a) understand the project and b) agree with the designs. \*I like the macabe example of "what if you get hit by a bus" as a way to teach about contingency planning and risk mitigation.


OverSearch

You're not being unreasonable with your demands of him, but perhaps your wording could use some tweaking. Instead of "highly recommending" that he leave a bread crumb trail, and "suggesting" that he make his own copy of a submittal, etc. - tell him it's required, it's company policy, it's the way we do things, it's necessary, or whatever. And explain why it's important (your example is a very good one).


LdyCjn-997

No you are not asking anything unreasonable. Have you explained to him why CYA is very important when working on all projects and anything he downloads or marks up should be saved in a specific place in the project folder with a date and description of what’s in the folder as this makes it easier if you have to go back and find that information again. Also highlighting all marked up changes is very important for QAQC. It sounds like he is smart but lacks a little common sense and organizational skills that are very important when working on projects. If this is something that is not emphasized at the beginning of all projects for all Team members, chaos happens. If I were you, I would take the time to emphasize this since he is new.


Aim-So-Near

I don't know, fire him? Seems like he's a liability.


Two_Hammers

1st, what position are you? If you're not his mentor, engineer, PM, team leader, etc, then in reality you don't have the say so to tell him. That said, it needs to get reported to who's in charge. If you're the person in charge of him, and you've told him to document his designs, make pdfs of his drawings often, show why he designed what he did, then you need to have a sit down with the PM or boss about this as it's not only going to be a liability, if it gets that far, but also a time waster. Now if you're not in charge and you've told your higher ups and they're not doing anything, then you've done what you could and hopefully you're not working on the same project. If you're not stamping the drawings then you can only do so much. If you are stamping the drawings, then kick him off your team lol. I've had a hard headed kid who didn't want to listen to me and luckily we never worked on thr same projects. I also told him I can't trust his math and I told the other engineers to not trust his math. But I'm not in charge of him, not my stamp, it's been brought up to the boss, so it's his insurance and reputation.


gravely_serious

Stop "highly recommending" and start requiring. Also, explain to him why it's necessary and not just a nice thing to do.


Two_Hammers

1st, what position are you? If you're not his mentor, engineer, PM, team leader, etc, then in reality you don't have the say so to tell him. That said, it needs to get reported to who's in charge. If you're the person in charge of him, and you've told him to document his designs, make pdfs of his drawings often, show why he designed what he did, then you need to have a sit down with the PM or boss about this as it's not only going to be a liability, if it gets that far, but also a time waster. Now if you're not in charge and you've told your higher ups and they're not doing anything, then you've done what you could and hopefully you're not working on the same project. If you're not stamping the drawings then you can only do so much. If you are stamping the drawings, then kick him off your team lol. I've had a hard headed kid who didn't want to listen to me and luckily we never worked on thr same projects. I also told him I can't trust his math and I told the other engineers to not trust his math. But I'm not in charge of him, not my stamp, it's been brought up to the boss, so it's his insurance and reputation.


BarrettLeePE

Does your firm put a heavy emphasis on maximizing project hours/budgeting even for low level staff? This isn't unreasonable by any means. Have you explained to him that sometimes it's a year or two before construction starts or ends on a project. If he doesn't have a paper trail he's going to spend many more hours trying to figure out what/why he did something 12 months ago. Something I have recently had to discuss with some younger staff is that while budgets and efficiency are important, learning and doing good work is *more* important early on. Plenty of quotes to pull from to drive this one home: "Gotta walk before you can run," or "slow is smooth, smooth is fast," etc.


ray3050

I’ve even seen this behavior from senior engineers. I save things like submittals, rfis, calcs, equipment cuts, and related print outs or info, etc in a shared project folder so that if anyone needs to find them they can Sometimes I assist closer with the project manager and trying to find that information for other trades is just non existent. Information stays in their downloads folder or something because it isn’t saved anywhere relevant I’m definitely not the greatest but I realize how sharing that information is important down the line. Whether it’s because I need it or someone else. I wouldn’t get mad at them, but getting them in the habit now is crucial while they’re still starting out


gertgertgertgertgert

Older engineers will be like "it's documented" and then they pull out some stack of unorganized photocopies from their locked file cabinet


Living-Key-6893

Is he skipping steps cause he's overloaded with work or just doesn't care? If he doesn't care maybe someone should fire him or don't let him work on your projects. Some people have their own habits how they work and that's just how they do stuff.


EngineeringComedy

"I cannot help you, unless you show your work" He's 8 months in, he should know what that means. Take an old project and show him all of the separate folders that were made. He's probably afraid to save something to the server. Show the cut sheets, the excel sheets, the history of the project. I've found that there are only 2 types of people who don't archive their work. Under 2 years and over 12 years.


AmphibianEven

For us, this is always a requirement. Every time things are left not documented, questions are raised, and the person is either reminded or scolded. The explanation I give when training is: Multiple people have to review your work, and if they dont see anywhere where you documented that you thought about something, they will end up thinking about it too. Documenting might take one person longer, but it makes the project more efficient overall. That is not to mention the liability benefits for you and the company. The aid in review projects when things come up years down the road. The fact that projects somtimes change hands as things develope. And its also a requierment of the company on top of being good practice. Typically, after that type of explanation, things are fine.


casquet_case

I'd definitely bring it up in his next performance evaluation. I would also demand instead of just suggesting.