What I learnt in creating a R&D Team?
Blog# 21, 07-May-22
I started my career as a software developer in 1991. Along the way, I learnt how to design, lead a team and such. I did software testing for few months for a product and loved it. But that was just for few months.
I joined another consulting company and moved to the USA and worked in various software development, product implementation projects. I got an opportunity to do software testing for a project in one of the largest banks in the world, which was headquartered in San Francisco. I did manual testing — looked at the requirements, wrote test cases, executed it, marked the results as pass/ fail, logging defects, created test reports and shared it with stakeholders.
I noticed that another vendor was doing test automation — which means — using a software to automatically do the testing. He showed a demo of that to the customer and I watched it from the sidelines and was fascinated by it. I had no clue how to do test automation. I asked the vendor how to do test automation and he told me, “Shiva, you are a manual tester. This is complex software coding. You won’t understand”. I insisted and then he told me that he used a test automation product called SilkTest, which is a commercial product. I did not have the license of that product and hence could NOT do much about it.
Around that time, the bank created a software testing team and I became part of the larger team. This testing team had two licenses of Rational Robot, a test automation tool, but they did not know how to use that. I asked for permission and spent time learning that tool. I realized that it used a programming language to create the test automation scripts. Since I had experience in software coding and design, I put together a quick and dirty design — test data in a database, screens which are used across test cases in a library etc… and started creating test automation scripts.
I showed the demo to the client and they were impressed. I learnt a lot of things in that process — why test automation scripts failed, how to reduce test automation maintenance, etc… I built a small test automation team — who primarily did manual testing and some test automation as well.
When I saw that the testing team in the bank was spending a lot of time, effort in creating test data manually — which was slow, error prone and expensive, our small army of test automation team automated test data creation. It was a huge hit across the entire manual testing team — since it was a massive savings of time and effort for them.
After sometime, I moved back to India and was doing various roles and the company decided to start software testing practice as a separate division. I requested for that and got the opportunity to head the software testing practice.
At that time, software testing was in infancy and we had to create our own models of recruitment, training, creating career paths and such. It was exciting to create something new.
The business and the team grew rapidly. We provided software testing services (Manual Testing, Test Automation, Performance Testing etc…) to various clients across the globe. I had a team of energetic managers who had decades of experience (mostly in development and some years in testing). I did NOT have a R&D team, though.
A person by name Naveen joined us as a fresher. He was shy, hesitant to speak in English. 2 years after joining the company, he showed me a test automation demo. This was NOT about creating automation scripts using a test automation tool. But creating a product which will automate the creation of test automation scripts. Kind of automating the automation.
It was raw and crude. It was also beautiful!
I started spending time with him and gave him some ideas to make it better and he completed it and showed it.
I told Naveen, “I want to create a R&D team for our testing practice and I want you to head it. You will report directly to me”. I called for a meeting with my direct reports and explained how R&D could help us create innovative solutions to our customers which will enable us to grow even more rapidly. They all agreed. I told them that I want Naveen to head it and some of the managers were aghast. My direct reports had vast experience and Naveen had 2 years of experience who would share the seat with them in our meetings. I understood their discomfort. I told them, “Let our focus be on who creates value. Not on who has the most experience”.
Naveen was equally hesitant and I gave him the confidence that we were all there to support him. We started putting a few things in place -
a) Choosing a name — Naveen suggested some names and we choose Innovez from that.
b) Navigating without budget — At that time, we did not have the budget to create a R&D team and none of the other divisions had any R&D team. So, getting approvals for creating a dedicated team would take its own sweet time. Hence, we decided to create a R&D team based on “volunteers”. These “volunteers” would have to complete their day job and then spend extra time to work on R&D initiatives.
c) Choosing R&D Members — We decided that we wanted only passionate people to work in this team and it was NOT for the weak hearted. Those who wanted to be part of the R&D team had to show a demo of what interesting/ innovative things they did, go through a grilling interview to be chosen for this “R&D Volunteer” team. Out of many who applied, we chose very few members and created a small team. They were energetic and were eager to change the world.
d) What to focus on — this was key. Instead of creating innovative products which would take longer, we decided to focus on “Accelerators” — which can be created in much shorter duration, but will add immediate value.
e) How to Build — In our view, innovation meant -
- Building solutions from scratch
- Customize innovative solutions of others — For example, MindMaps used by Business Analysts to create requirements in a visual format were customized to create Visual Test Design which clearly showcased positive, negative, destructive test flows. It was faster to create by our testing team and easier to review by our customers.
- Learn, Pilot, Deploy — Proactively search for solutions which were already out there in the web, try it out, if it works — deploy it
f) How to institutionalize it — Innovation in the lab is one thing. The most important thing is for more people to use it and benefit from it. Once we were confident of the innovation, we created training materials, identified more projects through our managers and deployed it. Customers loved it.
g) Rewards & Recognition — R&D Team members got better visibility with the testing practice management team which enabled them to get faster career growth.
Did it work? Oh, Yeah! From creating accelerators, the Innovez team moved further — created test automation frameworks, made it open source, got Award for Innovation and more.
What happened to Naveen? From being a shy person who was uncomfortable speaking in English, Naveen grew to giving presentations in conferences across the globe, energizing thousands of people on innovative solutions.
What did I learn from this? If you have money to create a R&D team that is great. If not, don’t wait. Start with wherever you are and with whatever you have. R&D is extremely important to grow. Relentlessly focus on choosing the right team (who can add value; not just on age), move ideas from the lab to the field, learn iteratively and so much more…
Will this approach work for you? Who knows? Unless you try, you will never know. Isn’t innovation all about trying something different? Go ahead! Try it out! Let me know what you learn!