Best Engineer to Staff Ratio

This is something that will vary so much by circumstance and individual situation that I'm not sure rules of thumb, or what other people do, will help much.

I will say that when my department had significantly less junior staff than senior staff, things seemed to run more smoothly. However, we were spread across multiple projects, sometimes part time on several, so it's not quite the same situation.

We recently had a project where much/most of the detail design & documentation was done by (a series of) interns. They had one experienced designer working with them. They then had the project manager, project systems engineer, and line manager guiding them on what they should be working on & how. Then just to confuse things more they also got some 'supervision' from and optical/mechanical engineer, a lead development engineer (or whatever his title is - think big brain socially awkward). Then they also had a related but for some reason mostly separate team working on another aspect of the project, which consisted of another series of interns and another manager, who'se electrical by background but loves to dabble in industrial design and the like.

Then, on occasion, when someone really had to get their poop in a group to actually get something released so we could start manufacturing, I'd chip in and crack the whip/take on some complex tasks.

With all the managers & senior staff coming from different view points etc, the people actually doing the work sometimes got conflicting direction.

This was night marishly inefficient.

KENAT,

Have you reminded yourself of faq731-376 recently, or taken a look at posting policies:

655321,
I think that your scenario is pretty common. The more experienced designer/EIT/Young PE can begin to handle some of the load. But until that individual(s) is trained most of the difficult design will bottleneck at the Engineer.

It also depends on the levels of ability, aggressivenes, self-reliance and communication skills of the junior help. Often a capable junior person can pretty much cruise in the right direction with minimal guidance and oversight. That requires fewer staff to run multiple projects. On the other hand, a room full of junior staff who cannot follow direction, or hide behind others, or just don't yet have the ability to make even minor decisions, will bog down a project. Oftentimes, we whom are supervising such staff become a bottleneck because we get caught up in either holding their hands, or re-doing things ourselves. Something we need to work out as we gain experience ourselves.

It really is an industry, project and company dependant situation. There are so many variables as has been stated that it is impossible to suggest one ratio over another.

Regards

It is not always the boss, nor the Junior engineer's fault.

Sometimes it is sort of job security on the part of the senior guy.
The senior needs to learn how to delegate more and more complex tasks and challenge the junior guys, just lead them, show them what is relevant on contract documents (and check behind them) so they won't spin their wheels over irrelevant stuff, and they will do fine.
Of course, you have to know how to locate the talent, know who to trust, who to check more often, who to delegate what?, limitations, etc.
Some seniors are truly "gate keepers" and they would rather take the knowledge to the grave than share it.

Engineers don't seem to do a good job at delegating, most are in their cubicles all day, not saying a word to their peers. I see engineers finishing a project without ever bouncing a single idea off their colleagues. This is very true with computer savvy engineers (i.e junior and senior), they think they can solve everything with new Excel spreadsheets every day.

Most of the time (and I say MOST), workload is manageable, if people are willing to teach others or just plain talk to others.

Working with this senior level engineer has taught me, the only reason the senior engineer is the bottleneck, is he/she has not found a competent jr to off load on. Makes you wonder about the level of knowledge that is applied to jobs.

Back when I started running projects on my own and then training junior staff to take over minor tasks, and then increasingly more complex tasks as they gained experience, I was able to build a department of highly efficient, knowledgable and effective designers. Some with limited formal education, but with common sense, a sound grasp of basic concepts and the ability to go forward with minimal supervision. This allowed me to basically run several project teams very efficiently, with a lead engineer or designer, and two or three junior design staff below him or her. And with well established set of design guidelines and standards so that we weren't re-inventing the wheel on every project, we cranked out a large amount of work.

Well now all those project engineers and designers are doing basically my job at other companies and the new generations of staff do not have the time, attitude or inclination to attack tasks with a sense of responsibility and ownership. Where I once was able to mold a draftsman into a designer in a year, I now have "CADD operators" whom believe that all they need to know is how to input data without regard for what it is, what it means, what it does or what it costs. Some of these do this for years without any marked improvement. I get more details back from them that look as if they were drafted by Picasso, than I do that look anywhwere near constructable.

In these days of excessively short schedules, tight budgets and lack of personal responsibility, I pray for just a few junior staff that have an interest in learning and applying themselves to performing a task with pride and sense of ownership..., well I can dream can't I?

Attributed to Abe Lincoln, an answer to how long legs should be, "Long enough to reach the ground."

Since you can actually see a bottleneck, then the ratio is not right for your organization. As mentioned above, either your engineer is too slow, or doesn't delegate enough, etc. However, whatever solution works for your organization will probably not work for another.

TTFN

FAQ731-376