“Don’t stop coding” says Technical Architect, Ayonam Ray

Ayonam Ray is a Technical Architect, Compilers at Poseidon Design Systems, a technology company offering products and services in Enterprise System Level (ESL) design space. It is interesting to see how an engineer with education and interest in “High voltage engineering” and with no formal education in computer science evolves into a Compiler Architect. Here is an excerpt from my conversation with him.

Career at glance:
Sept 2006 – present, Technical Architect, Poseidon Design Systems Pvt. Ltd.
2004-2006, Senior Member Technical Staff, SoftJin Technologies Pvt. Ltd.
1998-2004, Software Analyst, HP India Software Operations, STSD
1997-1998, Synergy Infotech Pvt. Ltd. (recently acquired by Sonim Technologies)
1996 M.Sc.(Engg.) High Voltage Engineering, IISc, Bangalore
1993 B.E. Electrical Engineering, Govt. College of Engg., Karad

Vinay: What is your current role?
Ayonam: Currently I am incubating a technology group in the area of compilers. I am leading the team technically and am completely hands-on. I do coding, defect fixing. My team is young and helps me with testing. My role is to do this and keep the team motivated. As this group matures, I would be mainly architecting solutions, doing some amount of coding, and then charting the future course of the product and its roadmap.

Vinay: How did your career evolve?
Ayonam: I never wanted to get into this industry. I wanted to pursue my PhD in High Voltage Engineering and got an admission to University of Southern California but I could not get a US visa. Then I dropped the plan and took up a job in Synergy Infotech, working on Systems Engineering. I started with porting gdb for a RISC processor and then a compiler for a micro-controller. From that point on, it was only compilers. Subsequently, I joined HP, first as a consultant and then as an employee. At HP, I got involved with a cutting edge product, a dynamic binary translator, which translates a PA-RISC binary at runtime without any recompilation on the Itanium platform. This was a flagship product for the migration to Itanium. I spent 5 years on that product. Subsequently, I worked with a client for a year, supporting the client on our developer toolkit. That was the first time I got exposed to the mind of the customer. I got to see for myself what the customer feels compared what you see in the Lab. After HP, I had a short stint at an EDA Company, SoftJin Technologies. I had joined SoftJin in anticipation of working on compilers, which never happened. Hence, I moved on to join Poseidon to start, rather regroup the compilers group.

Vinay: Any specific incident you recall on this “mind of customer”?
Ayonam: One incident came to me very hard. We had a design for thread local storage (TLS), which required any library with TLS to be linked at compile time itself. It could not be loaded using dlopen(). The customer had a mechanical modeling product with a small executable perhaps a few hundred KB and they had 2500 shared libraries. And some of these came from third parties. Their release manager called me one day and asked, “What is this issue about TLS”. I said, “It is simple. All you have to do it link this shared library and it will be fine”. He said, “I have 2500 shared libraries and if each of them has to be linked at the compile time, can you tell me how many hours it will take for your linker to link it?” That is when it struck me what it means to understand the mind of customer and importance of keeping the design flexible.

Vinay: When did you decide that you want to grow as a technical specialist?
Ayonam: This happened within 2 years of my career when I started working at HP. While working on the binary translator, I started interacting with people with 15-20 years behind them and they were still coding. I realized the kind of depth they had in whatever they were working on. They would say, “Go and look at so and so file and this line”. They did not have to look at the code. That really impressed me. We also had a senior, Karthik, who already had 10 years experience with him. He was hard code coder. We were amazed. He would churn out 100K lines of code in 9-10 months time. He would put in solid technology, read papers, come out with various optimizations, and implement them. He was the role model for us. All these factors influenced me to think, “This is something to be”.

Vinay: What would you advice budding technical leaders?
Ayonam: If you want to be in the technical area, then you have to have a passion for engineering. You need to be an engineer at heart. You should be able to distinguish fine engineering from a bad one, not just in code but also in say a chair or a car. If you have a passion like that then you are cut for this. At no point of time, you should take hands off coding. Spend at least 25-30% time coding. I would strongly advice doing a Masters as soon as one can. It provides you with a perspective, which will take much longer on the job to develop.

But, we are a product company

Technical leadership consulting work takes me to various technology organizations based primarily out of Bangalore. I meet people in following roles: manager training, VP HR, VP/Director engineering, head technology or CTO, head of a business unit and India center head. By now, I am quite familiar with first responses I get after I introduce myself as a consultant assisting organizations in maturing technical leadership. One such peculiar response is: “But, we are a product company”.

As I try to understand the underlying assumptions behind this response, I discover either or both of following:

1. We are part of a global product company. Technology innovation is part of our DNA and technical leadership is very important to us. Hence, technical leadership is not our problem (at least not among the top few problems).
2. You seem to come from a services background (i.e. majority of your experience comes from IT services business). We are a product company. Hence, our challenges are different.

Both the assumptions have an element of truth in them. However, many times, I find that the element weighs much lesser than the overall truth.

I talk to senior technical specialists to understand the kind of work India center is doing. I ask what kind of contribution they are making to product roadmap either to the product features (called feature roadmap) or to its architecture (sometimes referred to as product quality roadmap). Usually answer is “none”. Hardly anyone considers mentoring as a serious responsibility. Assisting business development is not part of their agenda. Writing white papers or prototyping is unheard of. These are hardly indicative of a mature technical leadership.

The second assumption (services vs products) misses the most fundamental objective of a for-profit organization: economic value creation. For an engineering organization, it does not matter who owns the IP. What matters is what value you are adding. I have been part of services engagements where we had end-to-end product development responsibility including requirement specification (way back in 1998). On the other hand, I meet many technical specialists whos work hardly creates any value in the overall product context. Many times, product manager (who sits in one of the developed countries) does not have time for these people and one can understand why.

It is no surprise that Economic Times article “Grooming Technical Leaders” which presents technical leadership at Texas Instruments (which has created brand for its technical leadership) says that “While publishing papers and patents are important criteria for selection, a bigger criterion is the impact of the technology created by the engineer on the business”. It is time India centers of global product organizations start assessing themselves on the business impact due to technology creation and not just cost saving.