As a techie, you cannot escape the buzz around IoT, elastic cloud computing, data analytics, machine learning, AI and the like. Most of the deep testing we would like to do in these areas lack easily accessible knowledge sources and definitely lack good tooling. We are sure that larger companies have faced many of these challenges and have arrived at a number of solutions. But unfortunately, we haven’t found solutions available in the public domain. So we have decided to devote R&D cycles to tackle some of these problems. I am sharing our plan online in the hope that smarter minds than us can provide feedback on the path we have chosen to travel.

---

The risk and benefits of R&D

Spending money on open-ended R&D could seem risky for a small company like ours. But we are OK with investing on R&D because:

1. it gives us a chance to do creative work (employee morale ftw!)
2. it helps us get familiar with the latest technologies (… even if we produce nothing worthwhile)
3. we may end up attracting clients who are already working in these areas
4. it could help us hire engineers with similar ideas
5. we could learn about existing solutions. We bet bigger companies have already taken serious shots (or solved) at a bunch of these problems
6. we have already established a culture of R&D (look at this blog!) and directly benefited from it
7. we are in a decent position financially and can take this risk

---

Strategy

It is hard to come up with strategy when so much of what we are trying to do is new to us. Currently, we have identified two approaches:

1. Figure out where we can help. There are many skills somewhat tangential to the primary development skills in each of these emerging areas. For example, scraping, cleaning and maintaining data could be a valuable tangential skill to people working on Machine Learning algorithms. This could be a good entry point for the motivated tester.
2. Look beyond the engineering solution. To be useful as a tester in emerging areas, we think the following thought experiment will help.
   1. Spot a technical problem
   2. Assume the problem is going to be solved by someone else
   3. Imagine how we will test the solution

Obviously, just doing this much will not be enough … BUT we think this will give us a good starting point.

Note: We needed to make organizational changes to support this kind of work. We’ll follow up with posts about how we are experimenting with our hiring, on-boarding, training and team structures.

---

R&D has already helped us

We have had at least one person dedicated to R&D since mid-2014. R&D has worked well for us. It has helped us:

1. land new clients
2. look smart and prepared when we go to a new client
3. allowed us to train new hires quickly
4. helped retain technically inclined testers who do not get similar opportunities elsewhere
5. expand our skill set beyond that of a typical tester
6. gain confidence that we can solve problems and pick up new things quickly

---

What we have learned so far

Over the years, we have learned a few things (mostly via trial and error) about running an R&D unit within a services company:

1. Prioritize interesting over useful: We seem to get a lot more ideas by doing something that interests us rather than have a concrete goal. We stumbled upon a nice talk called Discovery without objectives that reinforced this belief in us. If you disagree with this point, we encourage you to watch the video and think about the arguments made in it.

 

2. Have roadmaps: Don’t bother being accurate or concrete (see examples in our next posts) and do not hold people accountable to achieving all items on the roadmap. Instead, use the roadmap just to get your colleagues started. Once people get started, they generate their own ideas and next steps.

 

3. Split work into small pieces: Make an attempt to break work into really small chunks. Ideally, each chunk of work should be done within one week. When a new hire is introduced to the concept of R&D, no matter how smart, productive and independent they are, they want to be able to show visible progress. They want to know what they are doing is useful in the short term. Giving them small victories is key to building their momentum.

 

4. Share the work: Making people share their work (e.g.: write blog posts, use public GitHub repos) forces them to articulate their work better. The shared output will serve as good reference material for your training program. Sharing work openly also results in Internet strangers wanting to collaborate and help you. Your employees feel good when strangers around the world benefit from their work and recognize them for it.

 

5. Take time to come up with good examples: We imposed this constraint to get over the habit of people doing things only at the surface level. We wanted to avoid producing tutorials and examples that end up being too simple to be useful. Coming up with a detailed (and interesting) example that helps the learner feel like they have made substantial progress is key. We make our employees come up with examples related to their hobbies. For example, if our colleague Shiva (an Arsenal fan) works on data scraping, he would pick an example of scraping data from the English Premier League.

 

6. Tolerate failure: Be patient. Let your employees know it is ok to fail on R&D. Most work that is produced will likely generate plenty of dead ends. No single person will have all the answers. People will get frustrated when they get blocked. We need to manage that and intervene and reinforce the belief that failing on R&D is natural.

 

7. It is difficult to onboard people: While our R&D sounds cool, our experience is that most employees struggle to adapt to the idea of doing something open ended. It takes an experienced person about 6-8 months(!) before they feel comfortable with R&D. It probably takes longer before they realize its value to the company and to their own resume! So provide a support system for new employees.

---

Further reading

Interested in what we are up to? Take a look at some R&D roadmaps we have created:

1. Qxf2’s DevOps roadmap
2. Qxf2’s Hardware and Robotics roadmap
3. Qxf2’s Data analytics, Machine Learning and AI roadmap

While we have split our R&D efforts into three logical pieces, we would like to stress that we understand that they are all inter-related. The testing we do will combine all these fields. We have chosen this split up just make it easier on the engineer. But when we work on a real world problem, we ignore these artificial lines and do whatever good testing demands.

---

Related posts

1. Where is Qxf2 headed?
2. The need for change (at Qxf2)
3. An introduction to R&D at Qxf2
1. Qxf2’s DevOps roadmap
2. Qxf2’s Hardware and Robotics roadmap
3. Qxf2’s Data analytics, Machine Learning and AI roadmap
4. An introduction to training at Qxf2
5. An introduction to hiring and onboarding at Qxf2
6. Experimenting with team structures at Qxf2

---

Arunkumar Muralidharan
I want to find out what conditions produce remarkable software. A few years ago, I chose to work as the first professional tester at a startup. I successfully won credibility for testers and established a world-class team. I have lead the testing for early versions of multiple products. Today, I run Qxf2 Services. Qxf2 provides software testing services for startups. If you are interested in what Qxf2 offers or simply want to talk about testing, you can contact me at: [email protected]. I like testing, math, chess and dogs.

Related posts:

Where is Qxf2 headed? An introduction to training at Qxf2 An introduction to hiring and onboarding at Qxf2