Once you have got past the POC claims in IT appraisals its time to meet its sibling RnD. While the POC claims are easy to handle emotionally the RnD claims might get any techies nerve :).
Research and Development shortened as RnD is probably the most important activity that corporations do. It could the hard research that is done or an innovative solution or marked improvement in service offered by what your corporation deals in. That’s about the formal definition. Much like how innovation, strategy, vision, etc are used in a very diluted fashion we have also got used to RnD as a word used in work life. The misuse of the word is hardly the problem.
RnD claims in IT appraisals are probably the largest claim that could be made for top ratings. The cases are often presented as crisis+void vs heroism as the formula. Sample the following.
- The team was completely new to flutter development and (s)he did lots of RnD in solving the critical issues.
- As we moved from local machines to prod (say cloud) we had many unforeseen bugs to close (!!) and (s)he did lots of RnD…
At times the claims are even sweeping …
- Nobody in the company had worked in AR-VR or IoT or BlockChain and (s)he did lots of RnD …
- (s)he had no background in this technology ( say a .Net person on Java project) and (s)she did lots of RnD …
- There were many critical performance/Security/Deployment/Usability issues and (s)he did lots of RnD …
If you see the structure of these claims it follows crisis+void vs heroism. We must admit that the person in question has put in lots of effort (and must be given credit/reward for that). And that’s about a fair job done as far as performance assessment of an Individual is concerned.
It’s the “why” of this structure that has a lot to reveal. The RnD claims made in appraisals hint at the following.
- The team is clueless about the technology
- The team was not offered adequate hands-on training
- The intended structure of knowledge flow/review/mentoring is not working
- The estimation/Design/Team composition is not correct or clear
- People are clueless about the complexity that enterprise-scale or products bring in (and the discovery of them is overwhelming and someone the does the RnD)
- In cases where project takeover/maintenance is happening it might signal a lack of documentation of various forms.
Beyond this list, there are many people-related factors that might be at play: naïve but disillusioned developers, a (pretending) architect in the team, a panic driven style of project management or even a deep organizational culture issue. All of these are complicated issues to solve and appraisals are not the time and place for them to be taken head-on. But if you have some influence or control on the techno-people aspect of your teams the above list has 2 good uses.
First is, of course, we can take this line of questioning and find out the extent to which we should honor this RnD claims. The list above serves as a simple and neutral line of probing.
Secondly is this is your TODO list. In my experience as a product architect which also was an in-charge capacity, we use these claims as inputs for
- Team training and Individual training ( Hands-on assignments, pairs identification, and so on)
- Team recompositions
- Process improvements
- Documentations, sample code snippets, bootstrap code projects
- and a big session of how to get help and where to reach out
This is a very broad list, in some cases where we could do deep dive into issues, we also realized that our training needed some fine-tuning. For eg. my freshers always struggle with ng-serve and exposing their apps on machine-specific IPs. In another case, few people could that fathom that their angular app and rest code can be packaged and run as single deployable (because the angular and spring boot were 2 diff training).In other cases, we realized that promises were not covered as part of training (and we needed them) and that the REST was oversold to them. But not everything can be so obvious and clear. Our rule of thumb to our team was “if you are struggling with something for more than 30 minutes please reach out to me”. In our case, I was the old man I/C of tech troubles in the team. But this 30 minutes timeout helped people a lot with burnout and avoided future RnD claims.
The session on “How to get help and where to reach out” is obvious but not intuitive. Read on. Between the time I spent in product and services we had this new assignment of rescuing a project. Between me our PM and leads we were clear on what design we need to do and how much effort it will take. We even had a detailed plan ready but the time criticality mandated that we get it right the first time. We needed a team that was skilled with the technology and was quickly to reach out when stuck. And we changed our approach to team formation and working.
We did not take new people from a list of xls offered and then call for a “discussion”. We instead called say 50 people in batches. We gave them a very diluted version of the piece from our design and asked to code something around it. Yes, something that they could reason out. Googling was allowed and so was copy-paste.
And then each one of us would pretend that we are secretly helping them pass the assignment and offer lots of suggestions and debate points. The focus was not on how well they could code a service or create a table-query it or write multi-threaded sorting. The focus was on to see if they got the solution construct right, could they understand when we told them to follow, the choices we prompted them to make or ignore a stackoverflow answer. The experience was enlightening.
People who did not know the technology struggled to find answers to their tasks online (in which case we would tell them to forget the task and code something and explain it(as sort of fresh start/second chance) ).People who understood technology could differentiate between applicable/relevant google /stackoverflow answers and also spot the correct but not applicable answers. People who were skilled at their craft, the ones who understood our tasks at the first sentence, then they would go to their favorite tutorial directly or could quote from a book where they saw it. All this while we were prompting them with different ideas, it was good to know that the ability to seek-receive help is a personal trait (and not related to your skill level directly).We could not only rescue the project but it also rocked (I had moved on by then time it finished). But most importantly we did not slog, no burnout and 7 years later our team members stay in touch fondly.
I am sure that these insights are not novel, there would be some study done on these aspects and a lot written. But to know that people didn’t know how to deliver code and didn’t quite get how to get help was not known as this major a problem. This also made me create a long session on “How to get help and where to reach out”. And I end my session on “if you struggle with something for 30 mins please reach out to me”.
And yes there are still many topics, techniques, and libraries where I and we as a team won’t have first-hand knowledge. We call these as exploration items in our sprints. Either experts or hands-on. The Millennials also loved this growing in into technology experience …
but none made a RnD claim and no brownie points asked for in appraisals …
Was your appraisal experience this lucky?