Tapan Misra

From my slightly short-of four decades of experience with ISRO, in different roles at all the steps of the organisational ladder and most importantly almost a decade as ISRO’s recruitment team and question paper setter, I have come to the conclusion that it is the team, not individuals, who build the product.

Facilities, funding, instruments, buildings etc. are mere facilitators. If a payload or satellite or launcher succeeds, it is the Team which succeeds. If they fail, it is the Team which fails to live up to the expectations. Very rarely a system fails because of hardware. It is generally the failure of the engineers behind the hardware, planning and strategy of their development, and the thoroughness with which the hardware was tested.

SISIR Radar is responsible for delivery of Deep Tech products we have envisaged and convinced our investors with the product and its market potential and larger social utility. I have trust in Team SISIR, which we built assiduously in the last six months, to deliver our promise to investors.

We selected our team with care. We realised the essence of learning is ethics, grasping power and knowledge. We gave more weightage to ethics and grasping power than knowledge. Our interviews and interactions were structured to evaluate these qualities in our probable colleagues during interviews.

There is an unfortunate commonality in our education system in all branches of science and engineering. We stuff our children’s brains with a sackful of information. But we never teach them how to collate and extrapolate their knowledge and harness their common sense to translate their understanding of science into a product of engineering. It leaves employers with the extra task of orienting their employees towards product development.

We were conscious of this reality. In our view, there is no point to restrict our focus to a particular few branches of engineering. Instead, our recruitment was broad-based, having specialisations in engineering, physics, mathematics even architecture and mass communication. Over time I observed that the broad -basing of expertise has led to a salubrious effect of removing subtle disdain, if not dislike, for other branches of knowledge other than their own, a common ailment arising out of too much specialisation of the curriculum. After all, true engineering calls for harnessing whatever expertise is required for designing and building a product.

Engineering without boundary is the essence of developing any Deep Tech product like SAR we have embarked upon.

We never want to give a big assignment to our colleagues whose results will fructify in the distant future. Instead, we break the goal into small assignments to our colleagues in Team SISIR which can be accomplished in a short time frame, like a couple of weeks or more. We loathe utilizing our employees as mere tools and “software runners”. Instead, we encourage them to investigate independently, go through literature themselves, design their own approach to analysis and validate their understanding by analysing in more than one independent way. We encourage them first to simulate on the computer before playing with the hardware. They themselves analyse the failure mechanisms. In the end, they savour their small successes by sharing them with their colleagues. Our aim is to enable our colleagues to enjoy a continuum of successes in small intervals rather than wait for months and years to see their effort fructify.

Our education system is designed for achieving excellence through competition rather than cooperation, a trait which leads to poor teamwork. The direct fallout is the aversion to sharing knowledge, a bane running through our academic and professional environments, stifling the growth of the culture of innovation.

At SISIR, up to 05:30 PM, you do your own assignment. But from 05:30 PM onwards, it is the sharing of achievements in the last one week through presentations to SISIR members. We have noted that this practice has led to alternate perspectives, mid-course correction of probable costly mistakes and a culture of explaining a result in more than one method. In these face-to-face presentations, I have only one advice to my colleagues – “Asking Costs Nothing”.