Developing Organizational Technical Competency

                                                                            By Suresh Randadath

Technical employees who join a product company, for a role related to implementing a product, often make an arduous uphill climb as they go through the process of mastering a software product that they are not familiar with. There are three factors that make mastering a software product difficult: Flexibility of the architecture, breadth of functionality and underlying technologies.

Flexibility of the architecture

Complexity of any product is directly proportional to the flexibility of the functionality and architecture. In highly flexible products, there is always multiple ways of achieving a given result. But it takes many months of project exposure before one understands the best possible way of doing a certain thing.

Breadth of Functionality

Richer the functionality of a product, the more difficult it is to master the product. Certain products grow inorganically as the organization goes through inorganic growth. In such scenarios the product metamorphosise into a product suite, with a plethora of functionalities added as it grows inorganically. As a result, organization will have very few employees who know the functionality end-to-end, as most of these employees would have grown up focusing only on certain areas of these functionalities. Such silos of skill development invariably form in large software products that undergo such growth. If these employees are someone senior like an Architect responsible for the end-to-end solution, this can prove to be too weak a link that can break the delivery quality. All these factors bend the learning curve that much more.

Underlying Technology

If the product is built on proprietary technology, it adds another dimension to the mastering challenge. The more is the proprietary technology used in a product’s architecture, the larger is the learning curve for obvious reasons. Many times this will require unlearning various things a new team member would have garnered over the years working elsewhere.

Given these three factors, that stretch and bend the learning curve in mastering a new product, let us look at specific activities an organization can take up, to develop technical competency among employees who are not familiar to a software product that they are tasked to implement for customers.

Corner Stones for Developing Technical Competency

There are four main corner stones in developing technical competency as follows:

• Training
• Project Assignment
• Mentoring
• Sharing

These four corner stones are expected to lay the foundation to make technical team members attain the level of competency required to implement solutions using a software product.

Training

While it is important to send a new employee through a training programme, it is equally important that such programmes are structured and tailored to the needs of the individuals and projects. As the complexity of the product increases, any attempt to put an employee through a rigorous training programme covering the length and breadth of a product can easily overwhelm a new employee, resulting in erosion of confidence the employee had while he/she walked into the organization. It is always more effective to impart training in stages, with sufficient time given between stages for employees to give them an opportunity to do hands-on work to consolidate the learnings.

Similarly, a one-size-fits-all kind of approach to training will prove to be more detrimental than beneficial. For example, the training needs of people supporting a product that is already implemented in a production system is very different to that of people involved in implementing the same product in production. Former will require more of troubleshooting and environment level knowledge and skills than functional design and development skills.

Organizations investing in training without considering these factors will be doing so at the risk of poor quality of delivery with employees low on confidence.

Ideally the cross-over time between projects is the right time to do a self-assessment of one’s technical strengths and weaknesses and then get trained in weak areas to fulfill the gaps in skills. I call such periods within projects and outside of it as Technical Rejuvenation Periods (see Fig 2). Organizations normally are focused on ensuring that the billable utilization is maintained in the acceptable level at all times. When the focus is on utilization, it becomes extremely challenging for technical resources to get the necessary breathing space between projects to undergo such training or mentoring activities. It is important for an organization to make selective sacrifices on the billable utilization to help new employees get those breathing spaces within and in between projects.   

The timing and the relevance of the training are two very important parameters that are often overlooked. Any training should be immediately followed by a project assignment that provides the opportunity for individuals to exercise the knowledge gained in the training. There is no use in taking a training on a topic that is not going to be used in a project in the immediate 2 to 3 months that follows that training.

Project Assignment

Needless to say, there is no substitute for hands-on work when it comes to building technical competency. But here again, Organization needs to formulate a healthy deployment model that will help leverage the strengths of individuals. Deployment needs to be as aligned as possible to the focused training an employee may have undergone.

During these assignments, it is also important to provide technical empowerment to employees. This may be in the form of giving the liberty to take technical decisions backed with a robust review system so that risky decisions are identified by a more experienced member of the team and corrective actions taken to mitigate it. The whole point of this approach is for the new employee to feel inclusive and empowered. This will go a long way in developing the necessary confidence for the new employee.

Organization should be ready to give time for the employee as he or she makes that slow and painful journey towards the goal of mastering the product. Needless to say, organization’s appetite to absorb any likely failures the employee makes, as he or she stumbles and falls during this journey, is paramount for the success of the employee.

Mentoring

It is difficult to find good mentors. Also, mentoring is often a misunderstood term. Many mentors make a mistake of solving/clarifying a mentee’s problem/query by themselves. If a mentee approaches a mentor for guidance to resolve a problem, typical tendency of a mentor is to resolve that problem and then explain how he resolved it. Though this addresses the immediate problem the mentee is facing, this approach is definitely not going to help in the growth of the mentee. A good mentor is someone who make the mentee think and resolve the problem on their own by giving cues or asking more questions back to the mentee than answering. Mentee then approaches the problem in multiple angles using the cues provided by the mentor and then tries to resolve on their own. Having said that, a good mentor would still keep an eye on how the mentee is progressing from that point so as to avoid any potential delays or risk the mentee might induce to that problem that could jeopardise the delivery.

As mentioned earlier on the challenges of dealing with a product that has a highly flexible architecture, unless there is a mentor available to guide a new employee, it becomes very difficult to understand the best approach to choose in a given situation. A very closely knit technical community also plays an important role to guide the new employee. Organization needs to encourage and nurture such communities and allow certain limited room for failures when a new employee stumbles and falls on his/her journey to achieve technical competency.

Mentoring also should involve delegation of work, where it is possible, effective and less risky. This will go a long way in developing confidence for the employee in taking on higher responsibilities or complex tasks. Such delegation also should keep long term succession plans in mind so that projects have a second line of defence when the first line of senior/experienced resources are suddenly not available or need to roll off the project.

Sharing

I have always believed in the motto “if knowledge is power, then sharing that knowledge is super power”. Sadly, there is lot of tacit information that employees hold to themselves. These can be intentional or unintentional. Intentional holding of information is due to job insecurity or to create an aura of having the knowledge only to themselves. It can be unintentional, because in the urge to finish projects under unrealistic deadline an employee seldom gets time to offload this tacit information to a form that others can consume (e.g. documenting these in daily journals or anecdotes). Once a project is completed, the employee jumps on to the next project to ensure healthy utilization of the company.

While customer and project focus are important, it is also important for the technical team members to have the urge to contribute to the community at large. Having the knowledge on the lessons taught by other projects in advance, helps senior members of the project team to proactively plan on addressing similar risks within their own projects. By continuing to work within the project silos, each new project will invent their own proverbial wheels time after time. And that is going to cause more heartburn in those projects. The senior resources of the project like Project Managers, BAs and Architects have a great role in propagating the project knowledge beyond the confines of their projects.

Today employees shy away from using the mountain of data that organizations possess from past project mainly because it is difficult to mine them. Project learnings should be easily mined so that new projects can quickly consume it when required.

Conclusion

Developing technical competency is an onerous task but can be achieved with the support of the organization and the relevant stakeholders as discussed in this paper. The challenges and solutions discussed in this paper are based on my experience in the industry, and these are purely my personal opinions.