What's the worst question you can ask your leads?

[1503-44]

There are many simularities between projects focusing on development of complex systems. As someone managing engineering projects, I am sure you cannot count the times you have asked your lead engineers and others supporting your project when each one will finish their assignments, but that is not the question that you should be asking. The linked article is written in the context of software development, but as you will learn, the lesson is very much applicable to management of engineering development projects and team management in general. Well worth the 4m read.

https://betterprogramming.pub/the-worst-question-you-can-ask-a-software-developer-ddbcd5956eb4

Statements above are the result of works performed solely by my AI providers.
I take no responsibility for any damages or injuries of any kind that may result.

 

[CWB1]

That article makes the same illogical argument that kills productivity in many poorly run offices - that someone or something is somehow special and therefore unpredictable, yet more than a century of quality studies, lean and agile processes, and highly efficient offices have proven otherwise in everything from manufacturing to software development to facility maintenance. Everything we do whether innovative or not consists of a finite number of small steps, 90%+ of which are the same between various projects. That repetitive nature allows PMs to easily and accurately predict how long a project or task should take well in advance given a minimum of input from the person performing each task and a database of past project plans for comparison. If a task isnt accomplished on time the first logical question is indeed, "when will it be finished?" to attempt to save everyone else's schedule from unpredictable turbulence. The second logical question is "why isnt it finished?" so that improvements/corrections can be made to prevent future tasks from falling behind schedule. Suggesting that a task cant be predicted bc its dependent on a myriad of other people and unknowns shows that it isnt broken down far enough and is a failure of both PM and the engineer performing the work - one of the most common planning failures.

Unfortunately, software development is not a set of predictable steps.

Managers — those who are still reading — are probably rolling their managerial eyes, as managers do. In their managerial heads, they think that it is I, Mr. Naïve Blog Author, who doesn’t grasp reality.

 

[1503-44]

"That repetitive nature allows PMs to easily and accurately predict how long a project or task should take well in advance given a minimum of input from the person performing each task".

If that were true all the time, then no need to ask any questions at all. When that's not true, the PM needs to know what's remaining. With that information, a knowledgeable project manager should know how long it will take to finish. I find that the more you ask and pressure your lead engineers when they will finish a task, the more likely they are to give you an unreasonably optimistic bs answer, basically just to get you to go away. So you go away and rearrange the whole project's schedule, only to find out in next week's progress meeting, it didn't happen like they told you and now you have to do it all over again. No. Thats not the way to manage a project. That's how to be a glorified scheduler.

I thought the point of the article was that if you have to ask your leads how long it will take and when they will finish something, then you do not have enough knowledge of the time factors involved in doing the various tasks within your project, or lack a good database of the same, to be a project manager. And that is what I see all the time. Supposed project managers that can't even tell if a sequence of tasks is in the correct order, never mind how long anything will take. Most dont know anything more than what the list of tasks, deadlines and persons responsible they are constantly revising exactly because they have no idea obout the reality of any of it. On the other hand when I have worked where project managers were not wet eared MBAs that can bearly load MSProject, all I need to tell them is ... what remains to be accomplished and what's holding me back. Usually its those things that an inexperienced project manager copied from a previous database not realising that all projects are seldom the same, where the problems are likely to arise and not allowing for those things in the schedule, then he wants me to cut my alloted time to complete my tasks to save his skinney little arse. If you are the right project manager for the job, all you need to know is what remains to be accomplished and if there is anything you can do to help push on. With that, you should know by when it can be finished.

Statements above are the result of works performed solely by my AI providers.
I take no responsibility for any damages or injuries of any kind that may result.

 

[CWB1]

If that were true all the time, then no need to ask any questions at all. When that's not true, the PM needs to know what's remaining....I thought the point of the article was that if you have to ask your leads how long it will take and when they will finish something, then you do not have enough knowledge of the time factors involved in doing the various tasks within your project, or lack a good database of the same, to be a project manager. And that is what I see all the time. Supposed project managers that can't even tell if a sequence of tasks is in the correct order, never mind how long anything will take.

IME PMs tend to be business degrees not technical people, even in the best run offices. That's rather irrelevant tho bc even among engineers there are many who dont understand the nuances of each others' work but need a high-level view - MEs vs EEs vs systems/software folks. If the individual tasks are broken down to the lowest, most simplistic level then even the most ignorant PM should be able to understand them well enough to know "what's left." They might not know how to run a bolted joint analysis for example, but if I have multiple, separate tasks for running BJA on a dipstick fastener, another for intake manifold fasteners, exhaust manifold fasteners, bellhousing bolts, etc then they know the couple fasteners I'm looking at and when I'll be done within a few hours bc the task itself is tiny. Granted, there are tasks which must be rather massive - durability testing where a test stand automatically runs 10k hours or a computer simulation that must run days, but the goal for individual contributors is to get every task broken down to a few hours.

In a poorly run office you gotta do what you gotta do. BTDT, doing that now actually bc in consulting I'm usually at the mercy of customers' PMs & process. If the PM cant/wont compare tasks back to previous projects then your timeline is likely going to change significantly from start to finish. Employees will also struggle to keep up at times and you will waste a lot of time discussing the timeline.

In my (former) best run office we spent very little time discussing timelines. We had three PMs, ~300 engineers, and a small group of marketing/purchasing/other business folks. At the start of each program the team would spend a couple hours together laying out the high-level project plan, then for a few weeks afterward each member would meet with a PM individually for ~30 mins to fill in the lower level. At those meetings the PMs were constantly referring to their database. If I said I needed to run a specific analysis or test they would tell me previous examples took X hours, had Y for a predecessor, and Z for a follow-on task, which really helped take the human factor out of planning. Minor issues/emergency changes aside, everything after that was simply executing. The project plan and tracking was fully automated, you received an email when all predecessors were complete and you could begin work. Once you received the email, you clicked a link to acknowledge starting the tasks and again once finished. If you didnt click start or finish within a few hours of the expected time then your supervisor was notified automatically to address the situation. Other than a cursory couple minutes in monthly design reviews with management, we didnt discuss timelines after the first few weeks of a program nor needed to aside from resolving the occasional issue. Everybody kept a full and very busy but extremely predictable schedule, and our usual 1-2 year projects were usually complete within 1-2 weeks of the original predicted date. The best part tho IMHO was the predictability allowed you to plan vacations and work travel well in advance and not return to a mountain of trouble. I have found in poorly organized offices that there usually isnt a good time to be away, usually when you leave is when you're unexpectedly most needed and there's always a mountain of crap waiting for your return. Coincidentally, in that best-run office I also rarely needed to interact with my manager. We traded emails a couple times weekly, usually for him to approve purchasing or CAD/print releasing, and I saw him in a monthly project/design review with other managers. Management didnt micro-manage, they expected us to do the work, be professional/competent, and communicate occasional issues/questions/concerns as necessary.