Managing Other Engineers
Managing Other Engineers
(OP)
Hello Everyone,
I'm sure this predicament has been discussed many times on this forum, but looking for an up to date viewpoint.
In my current position (small company of < 20 staff) I find myself being responsible for the management of the engineers (~10 staff). Being an engineer myself, I'm actually finding this to be quite difficult given we have a wide variety of personalities and experience levels.
The underlying tone is that the mid to senior level engineers do not want to be managed at all and make it clear they are disgruntled over having too high a workload. Yet they do not want me to help them manage their workload - and so the cycle deepens.
Our junior staff are more than willing to be managed but they also require the most guiding/ teaching, which I am facilitating but again our mid-senior levels do not want to help out with.
I was wondering if anyone had uncovered the holy grail of managing disgruntled engineers, I have tried discussing in 1-1's and in groups but it inevitably turns into a moan and groan about the Company. I'm at a loss as to how I can help out.
My other observation is that in the post-covid era, I do wonder if the increase in online meetings is actually making our work less personable and affecting our communication lines within our Team - may be a contributing factor to the above?
Open for discussion!
I'm sure this predicament has been discussed many times on this forum, but looking for an up to date viewpoint.
In my current position (small company of < 20 staff) I find myself being responsible for the management of the engineers (~10 staff). Being an engineer myself, I'm actually finding this to be quite difficult given we have a wide variety of personalities and experience levels.
The underlying tone is that the mid to senior level engineers do not want to be managed at all and make it clear they are disgruntled over having too high a workload. Yet they do not want me to help them manage their workload - and so the cycle deepens.
Our junior staff are more than willing to be managed but they also require the most guiding/ teaching, which I am facilitating but again our mid-senior levels do not want to help out with.
I was wondering if anyone had uncovered the holy grail of managing disgruntled engineers, I have tried discussing in 1-1's and in groups but it inevitably turns into a moan and groan about the Company. I'm at a loss as to how I can help out.
My other observation is that in the post-covid era, I do wonder if the increase in online meetings is actually making our work less personable and affecting our communication lines within our Team - may be a contributing factor to the above?
Open for discussion!
RE: Managing Other Engineers
RE: Managing Other Engineers
So what EXACTLY is the organisation and responsibility level here from top to bottom.
You sound like you're just trying to help them out as opposed to managing them, so something is seriously wrong here in terms of how the organisation is set up and the company needs much better definition of roles, responsibilities and reporting lines.
What's the history here in terms of growth, role of the founders / owners etc?
It's often seen that gradually growing from say 5 to 7 to 10 people is ok, but after 10 you need to go into a different mode and what worked before "John over there does all the design work, Bill does the drafting, etc, doesn't work anymore. But people hate change if they can't see a benefit.
Are you all working on the same projects or does everyone have multiple projects or some big, some small?
Consultancy so work goes up or down or pretty steady?
Tell us a bit more please.
Remember - More details = better answers
Also: If you get a response it's polite to respond to it.
RE: Managing Other Engineers
Thanks for the reply phamEng - The work is allocated to the team via myself (Manager). The engineers are not currently responsible for bringing in their own work/ Clients, but they are responsible for delivering the projects.
Thanks for the reply LittleInch - Our (engineering) structure is as follows:
- 2 Company Owners
- 1 Principal Engineer / Manager (Me)
- 5 Senior Engineers
- 3 Junior Engineers
- 1 Apprentice Engineer
It's worth pointing out that all the people listed above are still in 'technical' roles and actively involved in engineering work.
That's certainly what it feels like, I'm trying to tow the line of not being a micromanager and trusting them to manage their own time. However recently projects are slipping and the quality is not quite where I'd like it.
The business started a few years ago as just the two owners, year by year we are gaining 2-3 staff and bigger projects.
Our projects are small to medium in size and are typically handled by one engineer. Each engineer is allocated around 8-15 projects on a revolving basis, for them to manage and prioritise accordingly. I guess the size of projects is part of the pattern to why we are working independently as opposed to working as a Team.
RE: Managing Other Engineers
In any really small organisation, especially one which started small and gained people over time, there is a reluctance to change and also personalities and friendships with each other blurs the lines significantly.
The key to this IMMHO, is the two owners. They ARE the company and I'm pretty sure everyone looks up to them and respects their judgement and power as they employed them!
SO if it hasn't happened or if it has it needs to happen again and they need to call a meeting and state quite clearly:
The company has grown and with growth comes change, which is never easy for anyone, least of all engineers(!)
We (the owners) though need to know how projects are going, which ones need some help, cross fertilisation of ideas and allocate work fairly so that Joe and Jesse here ( the juniors) get some good experience and learn from Pete and Amber here (no idea of the M/F mix you have).
So that's why we appointed MRob909 to be Projects Manager ( or whatever title you have) to do this as we couldn't do it anymore.
Moving forward we will have an overall joint monthly meeting (no idea whether you do or not) and MRob here will have a general weekly meeting with everyone to run through projects, see where we are, address any issues anyone is having and how we can solve them and we expect everyone to cooperate fully with him.
Part of what we want to do is bring on Joe and Jesse so MRob will be helping them which will take some time - we've allowed for that - but he will of course be available for reviewing and approving as required.
So we (Owner 1 and owner 2) expect everyone to work with MRob in making this company a better and more successful place to work. We won't always get it right, but will try to see where we can improve when we don't, but this change is part of the growing pains of the company and we need to see it through.
How does that sound?
You are right about the WFH and lack of interpersonal time so the old TWAT (Tues, Wed & Thurs) is becoming a bit more seen as what is needed, but again, the OWNERS need to step up to the plate and be there also otherwise it will wither on the vine.
Remember - More details = better answers
Also: If you get a response it's polite to respond to it.
RE: Managing Other Engineers
The expectations of senior level staff should be to mentor and train younger engineers.
RE: Managing Other Engineers
Also, age can be a factor. Are the other engineers within, lets say, 10 years of your age or older and younger. I would expect the junior and apprentice engineers to be younger, but they may not be.
One last thing not mentioned, but is there any relation between the owner and any of the engineers; son/daughter or in-laws?
"Wildfires are dangerous, hard to control, and economically catastrophic."
Ben Loosli
RE: Managing Other Engineers
As to "overworked" staff, ultimately you need to understand whether there is a workload issue, a pay issue, or an issue with perception. Some folks are happy just having a job. Some love paid OT. Others hate OT even if compensated. Learning which type your staff is can be helpful to managing extra hours. If your staff is "overworked" in 40 hours its likely either their project timelines are pogoing (slow periods followed by rush), or the engineer is personally falling behind bc they're being lazy then rushing to meet deadlines. In either instance I would recommend smaller, more frequent deadlines to smooth the flow.
RE: Managing Other Engineers
How do you track time? Spreadsheets, or do you have a live database where everyone fills out a time sheet and it's automatically loaded and visible to management?
I have a much smaller shop than you're running, but using budgets to forecast and allocate my time has been a huge help. You need to determine average utilization rates for each employee. Most insurance companies actually get nervous when you approach 90% utilization for an employee. 10% of their time is usually not enough to do the extra stuff that having a job requires, doing the necessary continuing education, etc. And if 10% of their time is enough, then they're probably working too much and are more prone to making a mistake that will cost the insurance company money. I think my insurance company advises 80% utilization as a max target for billable hour engineers. Those are the guys that show up, run calcs, and go home. They don't work with clients, they don't do training, etc. Sort of the 'journeyman' level engineers and senior technical advisors if you have any. Younger engineers will be lower as they are having to spend more time learning and senior engineers will be lower as they'll have more managerial and business development tasks.
As work comes in, you know what you'll be getting paid for it and you know how much time your engineers can spend on it. You should also have a handle on the 'extra' work that tends to come in. Short fuse stuff that needs to be in and out fast - shop drawing reviews, RFIs, emergency services, etc. If each engineer works 40 hours, then make plans more than 2 weeks out limiting them to, say 32 hours less your normal 'short fuse' load. If they will be working on a project with a budget that they're expected to spend 120 hours on it, then they need a little over 3 weeks. Split it up as needed for phases, submittals, etc.
If you can do that, work load complaints will either go away or expose personal time management issues. Or perhaps technical shortfalls that need to be addressed. AND, if you have a live database tracking time and enforcing daily time entry, you'll be able to monitor budget consumption. If you're halfway through the schedule but only 15% of the budget has been consumed, maybe time to check on it. Either you've got a rock star making the company some money, or somebody's lagging too far behind.
The proof is in the pudding. Nobody will accept the change until they see a benefit. And they probably wont see the benefit until suddenly you're having a company cookout on Friday afternoon and everyone realizes 'Hey...remember when we used to have to work until midnight every Friday? Things sure have gotten better, haven't they?" But even then, they'll roll their eyes at you when you remind them to turn in their time sheets.
RE: Managing Other Engineers
For that small number of engineers, I would've expected:
1. Two owners bringing in projects, leading some of the projects, and distributing everything else to senior engineers. Allocate junior engineers to the work under the senior engineers.
2. You as another senior engineer, not in an echelon in between the owners and senior engineers.
How much contact do the owners have with the echelon below you?
Do the owners have good attitudes, or are they setting the example that's spreading to cause others to be disgruntled?
Are you and the senior engineers in contact with the clients and thus have a pathway to becoming owners?
What is your experience level compared to the senior engineers?
What is your seniority level compared to the senior engineers?
What do you mean by "manage"? "LEAD" is more 2023. "Manage" sounds like something from Office Space.
RE: Managing Other Engineers
Yeah, but it's shockingly common in consulting firms. Really top heavy with questionable chains of command seems to be the MO for a large part of our industry.
RE: Managing Other Engineers
I guess, but in the firms I've worked for the setups were more logical. (50-100 employees)
They were more like:
There are a handful of principals who have close client contact. One or two of them have more seniority, so might have titles like President or similar.
The principals bring in the projects. Each has 2-3 engineers semi-permanently working under them doing most of the grunt work. Each principal leads and mentors people on his/her team to get projects finished. As engineers gain more experience, they spend more time with the client, so there's a path to advancement.
There's not really anybody looking over the shoulders of the principals. If junior engineers or drafters need to be shifted around, they just work it out. No need for a middle manager. To me, if there needs to be a referee to "manage" resources, that in itself suggests a problem. It's like if a leader is having to rely on rank structure rather than relationships to get things done.
RE: Managing Other Engineers
I think this is telling.
In my area - second largest metro in Virginia - the only firm that I'm aware of approaching that size is multi-discipline. So their structural department is still about the same size as the other regional firms - I think 30 is pretty close to the max around here.
The number of firms that get that big are few, and they usually accomplishing it by branching out to multiple offices. If you can get there and succeed, you're probably doing something right. Like fostering a healthy and productive culture and establishing efficient chains of command within the company. Everyone stuck in the middling ground of 20-50 employees is likely stuck on this transition.
RE: Managing Other Engineers
Senior engineers are often the technical experts in their area. Some struggle with the concept of mentoring junior engineers. Many forget that they were also mentored quite a bit in the early days of their own careers. I know of one individual that mistakenly thinks they are self made, when it took years of mentoring to get them to know how to do most of their job. They would often state that "nobody taught me, so the others need to learn it the hard way like I did."
RE: Managing Other Engineers
Cheers
Greg Locock
New here? Try reading these, they might help FAQ731-376: Eng-Tips.com Forum Policies http://eng-tips.com/market.cfm?
RE: Managing Other Engineers
RE: Managing Other Engineers
I think you're spot on with identifying the way forward, and I'm sure a shift change in mentality is required. The challenge I have is of course the old 'we've always done it that way' saying and whilst I understand the balance of getting work out the door, the longer this is not addressed the more it stunts the company's growth.
Thanks Rabbit - I do think there are toxic traits within certain individuals at mid/senior level. On reflection, this is probably why I am taking the brunt of teaching and mentoring of the junior staff. I really want to avoid exposing them to these individuals at risk of giving them a disillusioned view of the industry. Totally agree that mid level engineers should be very hands on in assisting junior engineers.
Looslib - Asking some great probing questions, and there may be more uncovering of the issues in this reply:
I was not one of the first engineers, in fact I probably joined the Company at about the halfway mark to where we are now in terms of employees. I was brought in as a Senior Engineer but quickly promoted to current position, primarily due to me being able to bring in new Clients to the business.
Despite my position, all engineers (except the apprentice) are +/- 5 years from each other (30-somethings). The owners being 20 years in age difference (50-somethings).
Finally there is a senior engineer with a family relation to one of the owners.
Thanks CWB1 - I think you are quite right in your overview there. I believe the challenge that I have is making that firm delineation from Senior Engineer to Manager. Especially when the Owners insist on everyone remaining technical and involved in engineering calculations, drawings etc. Ideally (as you say) these tasks would reside with senior engineers.
My observation of the projects we have secured over the past couple of years really do not lend themselves to being 'good' jobs. They are often rushed, with unrealistic deadlines imposed from the Client. Difficult in turning these projects away of course due to the income they provide, and I'm sure this is not a unique problem to our firm.
Indeed it is - I have experienced it before in other companies and it amazes me still that one bad apple really can ruin the bunch.
PhamENG - Another great observation, this is actually something I have raised as a key area for improvement. We currently use a very basic spreadsheet to log project time, but then do not use the data for measuring project spend/ metrics etc... in essence, admin for admins sake.
I'm in discussions with the Owners on implementing a timesheet system which will allow full reporting, my view is without knowing our efficiency/ project spend/ allocation of time etc we cant possibly make any informed decisions, bizarrely it's proving to be difficult to convince them of the benefits for what is a small investment...
Thanks 271828 - I guess this is a product of being a small firm. Aside from job titles, our hierarchy is effectively flat, the Owners are still hands on doing engineering work.
All the senior engineers hold a similar level of experience. My break away is that I have my own Clients and bring in work to the firm.
The discussion of transfer of ownership/ legacy is still in its infancy.
TigerGuy - we can be funny individuals us engineers, it's basically thinking that 'knowledge is power, therefore I must keep all the knowledge'!
GregLocock - That's a great view to have, and I wish more senior engineers shared the same outlook to mentoring. I guess it reflects on my thoughts above, that if our KPIs are all geared towards billable hours then the mentoring can easily be put to one side in favour of project work. It comes back to company culture, and by not providing time to mentor junior staff the company is at risk of stalling their growth (either people leave or the knowledge is not passed on)...
RE: Managing Other Engineers
Any company leads from the front and my overall impression of your responses is that the owners don't see what the issue is.
Until they do and invest some personal capital in you and what you're trying to do you won't get anywhere unfortunately.
Sounds to me like you could up sticks and create your own company with a few of the better ones from this one.
Got any (probably difficult to enforce) non compete clauses in your possibly non existent contract?
But if you want to give it one try you need to articulate your concerns in a proper written out plan of action and present it to the two owners. If they like it you're in business, if they prevaricate and can't see the benefit of doing it a different way, then start to think seriously baout other employment or career options.
Let us know how it goes.
Remember - More details = better answers
Also: If you get a response it's polite to respond to it.
RE: Managing Other Engineers
RE: Managing Other Engineers
This, along with a few other comments, indicate that the ownership is a bit short sighted. I learned (and am still learning) a lesson with this particular point the hard way. In my view, your firm can follow one of two broad approaches to client/project acquisition:
1) Gobble up everything you can as fast as you can. Say yes to everything. There are a LOT of jobs out there and lots of money to be made. Especially when starting out, it's really tempting to go after what appears to be abundant, low hanging fruit. After all - it's ripe for the picking! The result? You get the clients nobody else wants! In most cases, there's a reason they don't have a go-to engineer! Most of them beat you down on your free and then drag their feet paying you. You get paid, yes, but it takes a while. You end up with quantity over quality as you scramble to get each job done. Your reputation begins to precede you and you're stuck working in this part of the industry....and many of your engineers begin to think the entire industry is like this.
2) Be discerning. You won't grow as fast and you may well have some lean times at first, but there are good clients out there! Sometimes it's a matter of waiting for the other guy to slip up. Let somebody else get tempted by all that low hanging fruit to the point they screw over their good clients and you can snatch them up. There are reasonable people in this world that know how long it takes to do a job right and are willing to pay for it. But you have to be patient, you have to be alert, and you have to be ready to pounce when the opportunity is there.
Transitioning from 1 to 2 is not easy. But it's worth it! Goodness...I can't tell you how much nicer it is to have 3 or 4 clients that supply me with enough business to keep my profit margins healthy while turning away at least one project every week, once 5 in a single day.
Not bizarre at all. Pretty common for entrepreneurs to pinch every penny for as long as they hold the reins. They'll never forget the sleepless nights when they weren't sure if there would be enough work to keep the lights on. That's good and bad. But it's also one of the reasons that very few entrepreneurs go on to be good CEOs. A lot of really successful companies experience big jumps in growth only after the founder leaves. (I worked for a sign manufacturer founded by an engineer for a short time. Good and successful company that had been going for almost 20 years. Had a good local/regional reputation. He decided to retire and the company was turned over to an accountant who knew how to run a business while still letting the technical experts do their jobs. I think it took 4 years under the new CEO to become one of the largest sign manufacturers in the US with a large portfolio of international installations and contracts with a lot of the biggest brands in the world. He wasn't afraid to spend the money on smart investments.)
RE: Managing Other Engineers
A small firm I joined 20 yrs ago, one of the 4 founders said the hardest bit was going from 15 people to 30 people.
All the systems used up to that point - simple spreadsheets etc, just didn't work anymore and they needed to make the leap into getting people full time to do certain roles which previously they or someone was only doing part time. Trying to do all this shit AND get work in AND do some of the work is going to end in burn out or collapse.
Sounds to me like the company is stuck in that rut and doesn't know how or more importantly if it wants to dig itself out.
A real "come to Jesus" meeting is needed with the owners I think to decide are they happy as they are or are they going to make the great leap forward?
They probably don't really know what is going in in the company other than month to month P&L accounts....
Remember - More details = better answers
Also: If you get a response it's polite to respond to it.
RE: Managing Other Engineers
Other than that, I recently read the classic book "The Peter Principle". It's a quick read and really describes what you're going through.
RE: Managing Other Engineers
Somewhat agree. The owners dont necessarily need to actively manage staff but do need to support the manager(s) they appoint within reason. Its actually fairly common for folks within the C-suite to have a single manager or staff member beneath them, handling daily operations and gathering data for the C-suite'er to act upon. At my former consultancy we had managers reporting to a chief engineer who reported to a VP. The VP spent most of the day glad-handing clients and working on high-level strategic decisions so couldn't be involved in the day-day engineering, but needed their input. Having the chief engineer report to him also meant the VP owned both sales & engineering, so the buck stopped there and it gave him a second set of eyes on critical decisions.
RE: Managing Other Engineers
Since this basically describes me I feel somewhat obligated to respond. When you have an engineering firm with a large amount of work in a specialized field there is actually little (if anything) that management can do to reduce the workload. In fact in many cases the "solutions" to high workload only add to the burden. There are several reasons for this:
1) Companies are not financially incentivized to decline work, even if they are already understaffed.
2) Price's Law: In any technical field roughly 50% of the results will be achieved by the square root of the number of employees. So if the workload increase by 30%, hiring 30% more employees certainly isn't going to cut it (assuming you could even find qualified people).
3) New hires from other industries or even from the same industry but from a different employer add little value to the work process for the first several months or even years of their tenure. It takes a lot of time and effort just to bring someone up to speed to the point where you can hand off work to them without a barrage of questions/interruptions.
4) People that aren't busy usually aren't busy for a reason. In most cases shifting work from busy employees to un-busy employees is ultimately counterproductive.
-Christine
RE: Managing Other Engineers
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: Managing Other Engineers
Turnover and training are expensive. Rebuilding a reputation takes a lot longer than losing one. And losing clients can kill a firm.
RE: Managing Other Engineers
Zooming way back to the beginning of the thread, this sentence reveals what is going on at this company. There is a culture of blame and not accepting ownership and responsibility.
When someone above says "the problem is people downstream from me" that's the dead giveaway. I'd bet a three-digit sum of money that the two owners are doing the same thing. Not accepting ownership/responsibility is contagious. Reading between the lines, I bet the senior engineers blame people upstream for poorly allocating resources, for giving them poor junior engineers and drafters, etc.
The following three books explain this stuff in detail. They're in a VERY short list of books I've read that I would call life changing. I wish I would've had that knowledge in my 20s and 30s. Looking back, I'm horrified at my own thought processes from that time.
All three are highly recommended. If you want to cut to the chase, then the third book is extremely quick and efficient, and has most of the info.
https://www.amazon.com/Extreme-Ownership-U-S-Navy-...
https://www.amazon.com/The-Dichotomy-of-Leadership...
https://www.amazon.com/dp/B07THC92JS?plink=yfB2B34...
RE: Managing Other Engineers
Reality is also that even companies with great cultures usually have a few odd senior staff members that need to be walked out. I've dealt with my share of seniors with lousy attitudes and worse justifications bc they were trying to protect their position or coast for years into retirement. If they're not disruptive and contributing to a specialty niche then they may be worth tolerating, otherwise they need to go elsewhere.
RE: Managing Other Engineers
If quality is an issue you 100% have too much work going on. Id hit the beake pedal a bit (loss of profit) until quality/attitude is sorted for the greater good going foreward
If you cant do that, Im affraid it aint lookin good :)
Edit: i worked in "your" company and ran, now managing 11 in much better setup
RE: Managing Other Engineers
To be proactive, I've dissected what I believe to be the key areas for our firm and I've scheduled a meeting with the Owners to discuss in more detail.
If anything productive comes from it - I'll update this thread to keep you all abreast.
Thanks again.
RE: Managing Other Engineers
Also if anything NOT productive....
Remember - More details = better answers
Also: If you get a response it's polite to respond to it.