Hi dejan95

Have you considered asking the designers themselves how they could improve efficiency, they are probably the best people to ask because they do the day to day work, they will be able to say which tasks could be automated and will probably suggest some software, the problem is that its often the cost of software or hardware that the company won't invest the money.
Talking of motivation, again involve them in the process you are trying to improve, I find if you ask people what they think it makes them feel apart of something. there's nothing worse for moral than a bunch of managers who have never designed anything deciding whats the best system or tools for the people that do.

I'm not sure how you quantify designers working at 50%, however I wish I had a pound for every time I have heard the statement "a drawing, oh thats just lines on paper" whilst that is perfectly true what these people don't see is the thought process which results in those lines on paper.

“Do not worry about your problems with mathematics, I assure you mine are far greater.” Albert Einstein

Incentives and bonuses. are great motivation.
also team management skills are a must, how to include every one in a weekly meeting. and mentoring
agree ask for input from them what they need.
organization skills taught to the employees, how to manage projects, increasing skills such as up to date software
and hardware,

dejan95,

What does "50% productivity" mean?

--
JHG

dejan95,

Forget the software. Do your departments talk to each other? All sorts of tools are functional in the hands of people who want to communicate and work as a team. Do you have any office politics going on?

--
JHG

Most companies use MS Project or other PM software to track standardized design tasks across multiple projects. Not only does that allow you to predict project timelines and cost for quoting/management purposes, but it also allows you to hold individual team members accountable for their workload/efficiency.

The companies that do best have their CEOs on the floor. They talk to engineers, assemblers, ask what they want or need to do a better job. It's not software and it's not procedures. It's motivated leaders.

OTOH if you are only getting 50%, I suggest they are only paid 50% of what effort you want from them. That is also a leadership problem.

An example problem that leadership fixed: our factory had numerous complaints that welded assemblies were in short supply so the assembly line was idle too much. Go to the weld shop and ask and they say they don't have all the pieces to complete the assemblies. Ask the machine shop and they say they only do batch operations for the full order, so all of one part, then all of the next, and so on because it is more efficient for them.

Leadership says - great, the machine shop shows really good productivity and is killing the company.

If not for a true leader going to the floor, the top management says, "The machine shop is the only area meeting the goals. Punish everyone else."

IMHO incentives are not a good motivator.

I agree with the question "what does 50% mean ?" ... maybe it means that mgmt expectations are 200% ? (nah, couldn't be !!)

I agree ... talk to the guys.

But maybe they are being lazy ... then sort and cut the bottom 10%.

Maybe they've been "flogged" for too long now and don't give a cr@p anymore ?

maybe you've got square pegs in round holes ? (ie people's skills are not aligned with their tasks).

Maybe its a case of "order, counter-order, disorder" ?

I personally disagree with the CEO on the floor, but he must be able to see the floor and to appreciate what he's seeing (as his own gauge on whatever BS he's being told. (BS? nah, never; well, hardly ever)

If you're managing them, what's your experience (in mgmt) ? Mgmt is a skill, separate for good technical skill. have you been brought in the "straighten the ship" ?

"Hoffen wir mal, dass alles gut geht !"
General Paulus, Nov 1942, outside Stalingrad after the launch of Operation Uranus.

Re 1) how EXACTLY are you measuring productivity??? Opinions? Real data (I doubt it)?

Re 2) IMO MSProject is the biggest time sink and anti-productivity tool ever invented. Keeping a giant MSProject file up to date and accurate is an enormous effort.

As mentioned above, fix any communication issues between groups first. This can be helped by colocating project team members together. And have frequent short status meetings (and this is not diving into a giant schedule file).

I'm not in management. I'm part of the design department. That is how I know about the productivity and the lack of it. We are really good friends with my coworkers, but by reading a lot of books (atomic habits)I believe we can become much better department. That is why I was asking for your help.

Sure - read "The Mythical Man Month" by Brooks.

1) Books written for management and self-help have very limited applicability to highly technical, information-driven work. I have a copy of Atomic Habits but I haven't cracked into it so unfortunately I cannot comment specifically on that book. I *can* say that many common office productivity volumes are exactly the wrong thing to apply to engineering design, where deep work and freedom from interruptions is crucial to productivity. There is a vast portion of the business self improvement books that are written for an audience of managers / executives who bounce from one fad self-improvement method to another, and a successful book reinforces all of their happy business instincts. Another internal task force. Another LinkedIn post about how wonderful this concept is and how it's propelling them to their next stage of thought leadership. </retch> Which is to say, I don't think highly of this genre of books as a whole. Read them, consider them, apply a little bit to your personal life where it makes sense. Knowing where to apply a new idea is 100x more impactful than applying things just to see if they work.

2) I agree with the statement about 50% productivity means little until it's clearly defined. Do you have engineers operating at 100% productivity for comparison? How do you define 100% productivity?

3) What is the accuracy of the teams output? What is the (real) cost of errors? Are the errors discovered within the same facility or do they hide until the components are manufactured elsewhere before they are discovered at assembly? I work in a department that generates one-off designs and all components are manufactured by subcontractors. We invest more time in checking our work because it's very costly to discover an error at assembly. Make sure your productivity considers accuracy appropriately.

4) Discuss productivity issues with the team. In my experience, engineering teams are pushed to perform design before they have adequate information in hand. Is Sales providing adequate detail of what is required? Are the "productive" engineers just making assumptions to keep moving forward (and what impact does that have when the assumptions are not accurate)? Are design changes impacting total engineering time? Are the designs being reviewed and stage-gated at the appropriate intervals? Are all of the designs getting the benefit of the collective experience within the team?

5) Re-use of design data is very valuable in these situations but only if you can find the right design to re-use. Do you have well-organized part master data, such that you can search the existing part masters and quickly collect the closest existing designs?

6) Automate. Automate what? I hear this all of the time - but it only take one or two additional variables to water down the value of automation. Talk to the team, get their input because odds are, they don't enjoy doing the tasks that really are suitable for automation already.

7) I agree that incentives usually don't work. It' hilarious and tragic when management thinks they can craft a system that incentivizes engineering to be 'better' and then management's myopic incentive makes things worse - and splits the engineering team between those who chase the incentives and let the consequences fall later and those who see a different big picture and won't let the incentives sway them.

8) What other departments does the engineering team support, and how much of their time is going to those tasks? At many technical companies, engineering is the catch-all starting point for all of the other departments to begin solving a problem - whether or not it requires engineering support. It could be that the most 'productive' engineers are also the most supportive to the company. It's not necessarily a bad thing, but it needs to be in the team time budget and considered for what it is.

9) How do you manage the multi-disciplined aspect of the design? Does it go through mechanical first, then software, and so on? Or are the design teams working concurrently? And how well is that working?

10) Talk to the most experienced engineers - there are very likely excellent design practices in the past that were abandoned at some point but could be brought back into current practice for quick wins.

11) How are new projects documented and brought into the engineering department? If the information is not presented in a consistent way, then it becomes a mess and much of the engineering time goes into investigating and constructing the actual project requirements. The team ahead of engineering needs to know exactly what they sold and engineering should not proceed until *engineering* agrees they understand what that is.

how big is your organisation ? your Engineering department ?

If you're "on the floor, in the trenches, at the coal face", then why (do you think) is productivity so bad ?

what is inefficient to you ? Are drwgs taking too long to get done ? Is there a lot of rework ??

what does your organisation do ? Repetitive build (like production runs) or prototyping (each job for a limited number of builds) ?

"Hoffen wir mal, dass alles gut geht !"
General Paulus, Nov 1942, outside Stalingrad after the launch of Operation Uranus.

"The department is fairly new" - How New? 6 months, 1 yr, 5 yrs?

What did the company do before this new department turned up?
Why did it decide to create this department?
Did it have a mentor in higher management? Is that person still there?

What type of work does it do? Innovative / creative concept engineering type stuff or lots of "turn the handle2 type design work where each thing is only slightly different to the last one?

What is your experience mix of experience / age / background? Too many of one type leads to an imbalance.

Project management is much more than simply recording and planning tasks, but Excel is only good for relatively small projects with a handful of people.
But any system I've ever worked with seems to be written by software engineers in order to do software type projects as its all they know. Other types get shoehorned into their way of doing projects. Also setting up and running these systems takes a huge amount of time which is rarely include din the budget.

How are projects set up, budgeted, resource allocated? All this is key to setting the whole thing up right. Get the basics right and the projects work well.

Are there multiple design changes? Again - set a basis of design and stick to it or pay, literally, the consequences of chopping and changing.

Some more information would help a lot.

Remember - More details = better answers
Also: If you get a response it's polite to respond to it.

A good manager, who has been in the applicable line of work, and knows how long a new green start from nothing project take to complete.
and knows that jobs have to be scheduled as such the a sometimes it requires working several projects, and releasing
partial work as the project progresses. so ya that's how an employee gets tracked. and how he or she is projected progress and is on schedule. Engineers make terrible schedulers, but sometimes unrealistic schedules are given, but that is life.

so to my opinion if the manager is lost and does not have enough experience, there is no magic wand, it takes years and years of experience. I tried to sugar coat it and I recommend for moral give perks, most but not all employees want to do a great job.
but to my experience they lack support from the management, it takes training, moral boosters, and a manager who takes care of his
employees,

I'm rather surprised by most of the responses given. IME engineers are usually focused on quantifying and mathematically analyzing everything, and usually abhor qualitative guessing, arbitrary meetings/discussions, and other tasks with no measurable outcome or clear purpose.

Scientific management has been around more than a century with libraries of books published on everything/everybody from Taylor and his predecessors to Toyota, Lean, and Agile methodologies. Its generally accepted as being a misnomer tho in that project teams self-organized under a project "manager" are far more efficient than dept teams with engineering managers doling out tasks. The engineering managers should always be behind the scenes ready to support, but not involved in most projects beyond challenging the work/timeline/budget presented in design and project reviews.

On a well-run project the engineer should be dividing his work into various standard/generic tasks up front and publishing them into a project plan in MS Project or otherwise. Size electric motor, design support bracket CAD, 2x bolted joint analyses, run bracket FEA, etc. The time allowed for each task is the mean time to complete those tasks on other projects, so building/maintaining a task library is needed. Project managers support these administrative and process tasks, they're data analytics nerds who create/maintain the systems/libraries/processes, help the team organize its timeline and budget, and monitor time and budget burn throughout the project.

CWB1

there are so many different categories of design, it would take a library to house them all, A senior manager with years of experience needs to be involved. mentoring young Engineers, and leading the way, now a seasoned well experience person, needs to be handled differently. Managers job is to report they are on schedule, and in budget. and quality of design. my two cents

whilst I agree with "abhor ... arbitrary meetings/discussions, and other tasks with no measurable outcome or clear purpose", 90% of my technical job is making decisions based often on little or no data. Of course I see the value of mathematical analysis, but when the inputs are mainly judgement, then there's no real reason for "excessive" precision.

"Hoffen wir mal, dass alles gut geht !"
General Paulus, Nov 1942, outside Stalingrad after the launch of Operation Uranus.

Quote (CWB1)

IME engineers are usually focused on quantifying and mathematically analyzing everything, ... and other tasks with no measurable outcome or clear purpose.

Apologies if this is nit-picky, but...

If they were quantifying and mathematically analyzing everything, they'd be scientists and/or analysts. Engineering is often solving problems without complete quantification and analysis. Follow existing designs / choose reasonable material sizes / repurpose components where the new application has the same or less loading - and keep moving along. There are subsections within Engineering where everything does get full-blown analysis (aerospace for example) but even there you must feed the analyses with imperfect data and assumptions. Some engineers twitch visibly at the notion of not throwing their most advanced analytical tools at every component, every time. In my world, perfection is the enemy of the next order / next paycheck and so the majority of the engineers need to sleep well without analyzing every little thing.

Circling back to the original post, managers who believe they are quantifying performance accurately, usually are not. It takes a particularly ideal circumstance or a particularly experienced and well-nuanced manager to measure engineering performance well and still foster a cooperative and supportive culture.

(ETA: I'm not against metrics. But in my experience bad ones are more harmful than good. Performance metrics need to be agreed by the engineering team as fair and the metrics cannot encourage a 'not my job' attitude and they need to allow the cross-functional work and support to continue to thrive. HR and upper management needs to understand that strict metrication will lead to team members having to choose between measuring well/ignoring all other needs or supporting everyone that needs engineering support to keep the business productive)

This is one of the very best threads I've seen.
Several truly insightful posts, in my opinion.

Quote:

when the inputs are mainly judgement, then there's no real reason for "excessive" precision.

Depends on how you define judgement and precision. I agree with the quote but differ on its application. Given the project/product's performance requirements, every engineer should be able to create their own reasonably thorough task list (sans time) for project planning. They're obviously not going to get the exact number of bolted joint analyses correct and may forget a small task completely but overall the accuracy usually varies very consistently with project length/complexity and also between engineers of similar experience. The big variance in project planning is when folks are expected to estimate the time needed for each task, hence the use of median times for generic tasks based on historic projects. There's also "planning poker" and other group-average estimation methods but IMHO none as good as historic data. Combine a consistent, in/accurate list of tasks with a consistent time for each task and statistical methods yield a pretty accurate completion date. That said, planning projects does get faster and can be done more accurately with experience, so nobody should believe the consultants promising overnight magic. Several of my past employers successfully limit themselves to 2% variation (one week/year) from planned to actual completion, even in dedicated research groups, but they've been following consistent planning process for decades.

Quote:

A senior manager with years of experience needs to be involved. mentoring young Engineers, and leading the way, now a seasoned well experience person, needs to be handled differently. Managers job is to report they are on schedule, and in budget. and quality of design.

Disagree. Companies have separate management and technical career tracks for good reason - bc management is its own role with its own set of tasks supporting, but not actually engineering. Efficient managers focus on being full-time managers, not part-time engineers. They exist to resolve the administrative/political/other fires that impede design teams, and also handle the plethora of high-level approvals and long-term business strategy tasks. Engineers should be working very independently and only see their manager a few times monthly - casually around the office, at weekly/bi-weekly/monthly 1-on-1 "personnel" check-ins, and in monthly design reviews. Juniors needing technical mentoring should be going to a senior engineer or tech steward/fellow/etc, not a manager who's been out of real engineering for years.

Most of my employers have been solidly in the camp that studies and understands every possible variance to pinch every penny and CYA against potential warranty/other losses. I honestly enjoy most of the extra effort as it can be very educational, and there's no real detriment to any one project as its company-wide. To each their own tho.

Quote (CWB1)

Disagree. Companies have separate management and technical career tracks for good reason - bc management is its own role with its own set of tasks supporting, but not actually engineering. Efficient managers focus on being full-time managers, not part-time engineers. They exist to resolve the administrative/political/other fires that impede design teams, and also handle the plethora of high-level approvals and long-term business strategy tasks.

Some companies do this, some don't. I've worked for both. Either one has major built-in risks.

Having true Engineers as managers is dicey stuff - first, if you promote people into management because they are good engineers you will almost certainly have terrible management. The skill sets / instincts / training are almost completely unrelated. Excellent engineers who are naturally excellent managers are unicorns. You need to train those engineers to manage and appreciate the business needs of the company.
Second, if you promote good management candidates from within Engineering, there can be resentment when the sophomoric 'new kid' becomes the boss. But I get it, when the new kid has real management potential and the other engineers just stand around complaining about management instead of engaging and contributing. I've also seen the types who will always say what management wants to hear rise rapidly through the ranks because (from a leadership point of view) there are so few management candidates coming up through Engineering.

Having Engineers on a seniority track parallel to management makes a lot of sense. I, for one, took a turn at management and left for a senior engineering position. While the toxic management team that caused that has now left, having a senior engineering opportunity kept me here. It takes plenty of energy and brain power to make physics work for us - so there are many engineers who want to keep engineering and apply their experience to higher level planning and projects. If management was the only path up, they'd leave, become neglectful managers, or simply stall and not realize their potential.

The trouble with having Senior Engineering positions that are not in management is because they completely lose influence to the management. I've said before, and get reminded regularly, that physics does not give a f&cx about you or your financial success. So if management or sales really wants a thing to happen, the senior engineers need to 1) be allowed to assess the new 'opportunity' for risk and 2) be in a position to build an appropriate risk management (damage control) plan into its execution. Many management teams get desperate and cut out the technical minds from the up-front work and aren't held accountable for their unmitigated risk taking. Then those valuable technical minds become fully consumed by those bad projects, which makes them leave or at least, less available to plan new projects, which feeds a vicious cycle.

Maybe I digress. But as always, good leadership respects nature's wrath and that Engineering plays a crucial role in defending the companies profitability from it.