Author: Vineet Srivastava
Practical guidelines to Indian engineers
Many engineers in India are working side by side with engineers from other parts of the world as part of global design teams. Yet even the simplest of electronics that we see around us has little or no connection with India. Why is it that a country that produces top engineering talent good enough to work with the best in the world looks like just a consumer, rather than a partner, in this global industry? Why do we not see a large number of electronics products that are ‘made in India’ or ‘designed in India’?
Obviously, there is no single or simple answer. Undoubtedly, several other countries have done a lot more to promote their industries. However, in this article I stay away from the policy aspects and approach this question from a purely engineering viewpoint. I take a candid inside look at the engineering community itself and explore where I think some of the missing pieces may be. I do not have any magic recipe for success, but I do make some suggestions based on my experience and introspection.
A bit too conceptual
In general, I think our approach to engineering is a bit too conceptual. We focus on fundamental concepts, which by itself is a great thing. Strong emphasis on theory is the bedrock of all good engineering. However, engineers in India spend a disproportionate amount of time studying books and papers, not actual products. In the process, we miss the evolutionary trends that products around us are continually going through.
Cellphone chargers used to be heavy and bulky. Today they are sleek and light. Internally, these devices have gone from being linear AC-to-DC converters to switching converters. There is no dearth of engineers who understand these terms. Yet I never got a definitive answer when I asked around why and how phone chargers have become light. In a similar light, the computer mice have gone from being the ‘ball and roller types’ to the ‘red sensor types’ to the ‘invisible laser types’. We will have no difficulty appreciating the theory behind any of these. Yet, I wonder how many have realized what that red light under the mouse was and where and how it may have disappeared in the newer mice.
There is a visible scope for engineers in India to complement their theoretical and conceptual knowledge with what I call the product and market knowledge. How are the concepts actually applied in practice? What are the specific constraints that different product segments pose? How have these evolved over time?
Good enough is fine
Quite often, what sells in the market or is practically deployed is not the most cutting edge from a theoretical perspective but something that just works. I recall tearing apart a wireless doorbell that my neighbor complained did not have range as advertised. It used a simple wire as an antenna for a spectrally inefficient amplitude shift keying, done crudely with a single BJT. I bet a communication systems engineer worth his salt would be expected to recite theorems in multi-user information theory and capacity of exotic communication channels. That is great. But hey, here is good old ASK, waiting to be optimized, and people are paying for it.
Where is the Problem Statement?
We have an instinctive impulse to jump towards finding solutions rather than defining the problem statement. Unfortunately, however, real-life engineering problems seldom come “pre-packaged” like textbook problems do. It will greatly help if engineers get into the habit of defining what they are trying to solve before embarking on the solution, however simple or small their assignment might appear. This is often a non-trivial and somewhat iterative process with assumptions to be made and challenged repetitively at every stage. But getting into this habit can potentially make us better as a community at defining problems and, by extension, products, rather than just being great at solving problems that have been defined elsewhere.
Our outlook towards test and measurement needs to change. Somehow, testing conjures up an image of repetitive, script-driven, mundane work. But in reality, test engineers play a make-or-break role in the product development process. Test equipment these days are sophisticated but often have their own nuances. Also, automated test suites produce huge amounts of data. Hence, laboratory testing requires a thorough conceptual understanding, serious planning, and a methodical approach to work, much like a detective. Our engineers will benefit greatly if they learn more about the architecture and working of test equipment. Also, engineers need to pick up data analysis skills and learn to create summary from the raw data. It is anything but mundane. I see many engineers struggling with this.
Related, the penchant for reverse engineering. I once demonstrated an early version of my company’s IC to a South Korean ‘test’ engineer. Trying hard to not reveal any inner design secrets, I found myself fast losing ground to his incisive reverse engineering and somewhat unconventional but directed tests that exposed several aspects of our internal architecture. The ‘black box’ no longer remained as black for him as we had planned. His understanding and experience were obviously at work. I see a huge scope for improvement in this sort of ‘why must this be happening’ questions amongst engineers in India.
Non-technical does not mean not-important
The trickiest part of a product development cycle is the journey from being a working lab prototype to an actual product deployed in the field. I have personally seen even great teams falter at this step. To mitigate this risk, successful product companies have engineers working closely with marketing personnel to exactly find out the requirements and challenges of a given market right from the very early stages of the design cycle. This synergy is yet to develop in India. Unfortunately, and I hate to admit this, engineers in India tend to show a disdain for anything non-technical. This must change.
Within engineering community itself, in my opinion, there is excessive compartmentalization. It’s time we came together and started seeing each other as holding keys to different but equally important parts of the puzzle. In this light, I think we need to get better at explaining our work to others in a way that they relate to so that we can mutually benefit from each other. Today, we tend to get too technical and hence often end up communicating to only those who are trained very similarly to us.
And finally, the dreaded D-word, D for Documentation. Many engineers are reluctant to pen down their thoughts though they are comfortable speaking about them in conversations. The trouble with keeping everything oral, apart from the obvious risk of forgetting, is that speaking gives us ample room to conveniently change our stance or to mistake a necessary condition for a sufficient condition, and so on. In other words, it hampers clarity of thinking and reproducibility of results. On the other hand, writing forces clarity, which directly shows in the quality of the engineering output.
The way forward
So where do we go from here? As I have mentioned in an earlier post too, we need a sort of maker movement within the engineering community in India. Engineers need to get their hands dirty and make stuff even if as prototypes or experimental projects. Start with a clear problem statement: it need not be grand or cool but must be clear. Analyze your design choices carefully: most makers today are not able to articulate why they have chosen a certain microcontroller, for example. This must change. Take your projects to a logical conclusion and present them at the various platforms that are available today to seek feedback and guidance. IEDF IoT Project Day is one such platform.
Similarly, try taking things apart and figuring out the engineering trends hidden in there. Read product datasheets. Discuss with your peers. Speak more to your MBA friends and learn to at least appreciate the business side of things: how one sizes markets, how sales and supply chains work, how innovations disseminate, and so on. In other words, learn how industries work. Engineering is more than equations and simulations. We are strong in those aspects. We now need to think beyond. I urge all to think products.
Author: Vineet Srivastava
Vineet Srivastava is a hands-on signal processing and communication systems engineer and has held engineering positions at a number of internationally renowned organizations, designing, analyzing and evaluating communication systems in different product segments. Vineet is generally very passionate about engineering and also runs an educational project called MyGadgetsSecondLife – Inspiring Engineers where he gets youngsters to dissect old and rejected gadgets to learn the science and engineering ideas hidden therein.