Part 1: The Lifecycle of an Engineering Task
Hire, instead of “Get it done”
This article is to (a) highlight a crucial problem that could be served by marketplaces & (b) kindle managers in Engineering & Engineering R&D to think outside the box while solving engineering challenges. As legendary Harvard Business School marketing professor Theodore Levitt put it, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole!”
😩 The Pain
Engineering and R&D Managers face issues in resourcing (finding the right talent for the task at hand) all the time. This is especially prevalent in Small & Medium Businesses as there is a war out there for the right talent. Many a time this pain is excruciating if the task is dependent on hyperspecialized resources who are not available at short notice.
📤 What is a Task?
Let’s start with the classical definition of a Task. Merriam webster’s definition of task is:
a: a usually assigned piece of work often to be finished within a certain time
b: something hard or unpleasant that has to be done
c: Duty, Function
Why is a Task important? Tasks are something engineers do every day, converting hand markup to AutoCAD, design 10 circuits, and whatnot… Hence, one might wonder why such a tiny step/activity in a process, is given so much importance and why there is a lifecycle associated with it. Read on…
👷♂️👷♀️ Task manifests itself in real life in engineering
Engineering managers maintain tasks as a set of to-do’s which their engineers execute on a timely basis. Most of the time, the execution runs smoothly. But sometimes, it so happens that a task starts to become a risk, which if left unmanaged results in an economic loss for the organization
Lifecycle of a Task:
Phase 1: This is the moment when there is a “shape-shifting” of Task. Depending on the Complexity or Criticality to Business etc. the task becomes a risk. Over numerous RCA’s (root cause analysis), we know the usual culprits are:
- non-availability of an engineer to do a task
- un-availability of the right skills to do a task (we will talk about nano-learning another time)
- getting the task done within a budget
- inability to get a task done while ensuring the right output
Our specific area of interest is to look at those Tasks which have a high tendency to become Risks (most engineering managers would remember an internal/external auditor nudging you to identify them proactively early on (even during the project planning stage) and add them to the risk list) in the project
Phase 2: Given the above situation, panic sets in, the immediate reaction is to identify the most helpful resourceful person to address the risk, tada… now after shape-shifting, the task starts to exhibit another complex character, i.e “Ownership shifting”. The ownership of the task moves to HR!. Big sigh of relief for the engineering manager!. Most often the mandate given to HR is to hire someone who can do this job on a temporary basis (freelancer/part-time etc.)
Phase 3: No sooner than the baton is passed to HR, the engineering manager gets the baton back. Now, the hiring manager (one who has the pain) has to write a job description, typically covering the engineering roles & responsibilities.
Phase 4: The easiest phase: The task now becomes a job that gets posted on multiple job sites.
Phase 5: Most apply to do this job. Though the ownership is now on HR & the hiring manager to vet each one of the applications, in reality, it rests mostly with the engineering manager. As expected, managers realize that what you see in the CV is not what you get (WYSINWYG). The hunt continues…
Phase 6: After an arduous rollercoaster ride, a candidate is selected, but with no guarantee for output. The organization ends up paying for hours and not the result. Luckily the task now has a new owner and moves away from the risk list back to engineering To-Do’s. Sigh of relief for everyone involved and life is back to normal.
Between Phase 4 and 5, there are some hidden loops that include disinterestedness of candidates to apply for the position and shortlisted candidates not showing up after the offer. All these issues increase the overall waste in the process of “getting it done” (yes, that was the starting point)
Imagine this being the plight of one engineering manager, the scale could be much bigger when it comes to larger organizations. This is where the economic value of getting things done matters. The system is broken; today engineering managers are hiring rather than focus on solving problems.
🧰 Summary & Takeaway
Just like software, other areas in engineering are also catching up fast in looking at efficient ways for teams to organize & engineer together, aided by the advent of platforms like Onshape and OneIPM. The time has come for engineering managers to embrace change and build on the latest developments in this area.
To start with, here’s a list that might help you initiate a self-assessment of the current situation:
- Do we proactively identify tasks that tend to become risks based on resource availability in the planning stage itself?
- What was the opportunity loss due to bad resourcing in your R&D or Engineering tasks?
- Do we have enough granular information of those tasks which are becoming risks?
- Do we have a practice of mapping the required competencies: across these tasks?
- Do we have a way of addressing resourcing based on item no. 4 internally or externally?
- If externally, do we capture the competencies, the rating across these competencies, and use them to pick a resource when needed?
- Do you have visibility to the availability of external engineers at short notice?
- Do you have access to a pool of such engineering resources who could be trusted based on their work in similar organizations?
- Who drives resourcing for such critical tasks? Could there be potential conflicts in ensuring successful resourcing for such tasks?
- Lastly, are engineering managers/PMO’s still working by “Ask your friend” when it comes to resourcing?
👉 Next up, “If it ain’t broke” 💔, why fix it?
