A key resource is nothing to be proud about. It is a dependency. It is a threat to the organization and blind spot for the resource him/herself. It is a flag for corrective action.
Let us understand the issues first and we can go on to the solution.
Key Resource is a threat to the organization.
Let me say that again, a key resource in the wrong place is a threat to the organization. So far key resource was considered as a good to have on the team. Let us do a little reality check and understand the paradox that key resource is the last thing that is required in an effective team.
One of the major challenges as a manager is resource management and that to a specific resource. As part of the duty, the manager is responsible for the smooth execution of the project and resource retention. It is often hard to keep that balance. If you look at it, the daily issues to be managed are more of the project related work, not the resource retention. So it is human to focus on the project work and to ensure that you would like to have the team in order. As this progress for few releases, there will be few favorites that have delivered enormous on the project and seem to make your life as a manager peaceful, So there is a birth of a key resource.
As in software, you need to keep this in mind that “change” in the only constant. Now we have been so far that we are heavily dependent on the key resource and are always preferring her/him for many things regarding the project. We do all that is needed to retain the employee either from leaving the organization or just the team. Now, the key resource is a bottleneck and a dependency to the project.
Red Flag: If a manager has an affinity towards a specific person to a role. There is a big problem.
On the other hand, the key resource her/himself might be loosing on the opportunities for growth. No matter how much you are respected doing a certain thing, you do not want to be doing the same for more than 6 months. Being critical to the project, the resource might well get stuck with the project.
So it is basically a lose-lose situation to be in.
But, not to worry OOP for the rescue.
Here, I am going to discuss few OOP concepts and principles that can be applied to resource management.
1. Hypothesis I: Program to interface not implementation.
The interface is a contract and implementation/realization of that contract. In this context of resource management here are the keywords.
Role: Role is an interface. It defines a contract that has a list of tasks that are required to be performed.
Resource: Resource is an entity that implements the role and performs the set of tasks defined in the interface contract.
Role is interface. Resource is the implementation.
Just as in case of a good software, here for a good team as a manager we have to keep the focus on the Role that is the interface and not the resource, the implementation. The Role should clearly define the set of tasks that are required to completely implement the interface.
Let us check with a simple example. PS: Simplified deliberately.

Here, the role defines clearly what exactly are the tasks to be performed. Mike is the resource that implements the role and does all the tasks that are in the contract. Mark, on the other hand, does not know how to do LLD so we cannot have him do the role. As Mike works in the role and gains experience and more expertise he now is also taking care if updating client. But this is not in the contract, so you need to consider Mike for a new Role and get an exact contract matching resource for this Role.
Advantages:
- Resource and Role are independent. This is very important as the Role stays unchanged for a long time but the resources change continuously.
- The resource will have more growth opportunity. As in this case, Mike may get a promotion.
- The role does not get adulterated by the implementing resource. It so happens as observed a particular Role executed by a specific resource for a long time gets influenced and the Role and Resource become interchangeable. This creates the high coupling and dependency that the resource becomes critical and hiring becomes a challenge.
- The manager has a peace of mind as he is focused mainly on the Role and not worried about the dependencies with the resource. The role is the one that is getting the desired tasks executed, does not matter who executes that. If a resource is already taking care of the Role, we can always Hire a new resource to do the same, as we did in the first place to start with.
- Low coupling and high cohesion with the resource.
- Freedom for Manager and Growth option for the resource.
2.Hypothesis II: Abstraction in assignments. Anti-Micro-Management.
As a resource manager delegate or assign work of what is to be done but not how. Keep the assignment abstract and let the resource do the implementation. Give them the clear expectation and make the required interface contracts that define the abstraction of what is to be implemented. Let the resource implement the task.
Advantages:
- The resource will be motivated by the trust given.
- Opportunity for better and varied solutions. Every person solves a problem differently
- The resource will be more responsible. Will ensure the end to end activities of the assignments. Rework and enhancements will be faster and better.
- Improves relationship. Encourages and motivates the team.
3.Hypothesis III: Exception handling.
Just as an exception handling make the system robust and self-corrective, we as a manager need to catch the resource doing something right and also look for areas of improvement. The feedback loop should be immediate just like the way it happens in case of an exception.
Advantages:
- If the feedback is immediate just like in case of the exception handling there will be the scope of recovery.
- Immediate appraisal and feedback motivate the employee.
- Immediate reprimand will give an opportunity for the employee to correct course.
- Just as in case of exception message with color coding and levels, we need to keep the feedback in the required color and tone to have the correct effect.
.
Will keep updating as I am able to convert the object-oriented principles to resource management. Please let me know your thoughts in the comments section.
Leave a comment