Blog moved to a new location

This blog has taken a new avataar. See you there.

Top 5 challenges of budding technical leaders

Yesterday I conducted 13^th workshop on “Becoming a successful technical leader”. During the feedback time, one participant commented, “Such sessions happen once in four years”. Well, it wasn’t anything like what you guessed. He was referring to the fact that it was 29^th Feb which comes only once in 4 years!

Jokes apart, it has been fun talking/discussing/presenting to these budding technical leaders (over 250 by now) from 15 organizations. I am presenting here the top 5 challenges of these budding technical leaders (what they feel are the hurdles in becoming a successful technical leader).

1. No opportunity: One common crib is that they don’t see much opportunity for doing cool stuff. Most of the work is routine (enhancement, bug-fixing). As an entrepreneur, this is a difficult one to agree upon for me. May be I am too used to finding opportunity in everything! We discuss various issues associated with product quality of a technology product and how technical leaders can contribute in improving it. For example, owning parameters like availability (uptime), maintainability, performance, security, testability, usability can make so much difference to the product.

2. No time: When someone says “no time”, usually it is a good time to check “Do you really love this activity?” Not everybody should become a technical leader. Perhaps you are destined to succeed somewhere else.

3. No incentive: Well, this is an interesting one. Sometimes we have participants say, “I get my raise anyway. Why should I do all this?” This is really a good one and quite true as well. Engineers from IT industry in India have been getting a raise anywhere between 15% to 30% for past several years (a decade?).

4. No mentors: Now, we come to the serious ones (at least in my opinion). Lack of mentors. This is a real challenge. Many organizations don’t have senior technical specialists and hence budding leaders don’t have anyone to go to. Perhaps, it is time people look for mentors beyond organizational boundary or within organizational boundary but beyond geographical boundary.

5. No role models: Role models play a key role in motivating people and these are in serious short supply as far as technical leadership is concerned. This is also a place where organizations have a key role to play. They should bring out role models and market them within the organization (I am tempted to say even “outside” the organization, but in today’s world of – war of talent – I know how silly it might look).

“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.

Beware of technical ladder roles

Technical ladder is getting hot (Sakkath hot, magaa, as Radio Mirchi FM channel in Bangalore would say). Look at Economic Times devoting almost of a full page on tech ladder in the article “Grooming technical leaders” a couple of weeks back. The article presents TI’s technical ladder, its broad characteristics and how it helps as a motivational tool for engineers. In fact Santosh Kumar, head TI, India Software Council and a Senior Member of Technical Staff quotes in the article that ““It serves as a useful tool to see how you are growing in the company; it provides a reference point when you go out and say that you were on the technical ladder people can immediately understand your contribution”

For those who may not be aware, TI’s technical ladder process and its implementation in its India center is supposed to be one of the most mature in the industry (especially among the IT companies in India). TI has been leveraging “mature tech-ladder" brand for a while now. See, for example, how technical ladder is described as an important tool to motivate talent in this article when TI, India was declared No. 1 in “Great places to work” survey in 2004. Similarly, in the cover story “Texas Instruments: Taking charge of the Indian electronics environment” appeared in Dec 2007 from Smart Techie magazine, Dr. Bobby Mitra goes at length to explain how technical ladder is at the heart of innovation in TI, India.

If you were to take this story and extrapolate it to the rest of the IT industry in India, you will be grossly mistaken. Remember that TI, India is the oldest MNC to set up a shop in India. Moreover, first full product called Ankur came out of this center way back in 2000. However, HR in IT companies is getting really impatient and running out of ideas to attract and retain talent. Hence, it is not surprising that many organizations are advertising for roles such as “Architect” or “Technical Specialist” to attract talent.

This is the story I heard from a co-passenger in a train from Kolhapur to Bangalore earlier this month. His friend changed his job as he was being offered an Architect role (with, of course, significant raise). In fact, the company had advertised multiple Architect positions. It has been 6 months since the fellow has joined and he has no work.

It is true that “technical ladder” can be a good motivational tool for engineers passionate about technology. However, it can’t be sustained without a fundamental business need. If you are considering such positions (internally in your current organization or externally), you should ask the question, “Does the business really need this role at this point?” You may take up such a role in spite of business need not being clear. In which case, you are taking the responsibility of influencing the senior management in demonstrating how this role adds value. This may be an uphill task. But, hey, who says life is easy?

Software architect community in Bangalore is largely a disgruntled lot says Yuva – Part 2

In part 1 of my conversation with Chief Test Architect, Yuvaraj “Yuva” Athur Raghuvir, talked about his current role and about the architecture validation process. In this second part, we will see how Yuva’s career evolved and his movement from a “development manager” to “Chief Test Architect” role.

Vinay: How did your career evolve? And at when did your specialization get defined?

Yuva: I started my career in 1996 in K&V which was acquired by SAP 1999. In K&V, my first work was in the area of CASE tools. Here you model the application on certain framework and then you generate source from the model. When SAP acquired K&V, I was asked to look into the area of repository design related to application repository services (later called mobile application repository).

When I moved from CASE tools to repository, my domain was still not clear. My domain expertise in the area of logistics software design crystallized 2-3 years down the line. In 2001 I became development manager for the same team, responsible for development and delivery of meta-data repository. Initially I was managing a group of about 8 people and a project. Over the years I started managing 2 more projects and team size increased to 25. That is when I got interested in the area of test architecture.

Vinay: What were the exciting moments you recall in this journey?

Yuva: First thing was design of the mobile application repository. To build a versioning system on the relational database with an object oriented access. To also manage the amount of database loading you need to do, how you split the object. It was cool.

After that it was largely in talent management space. It is to figure out how to handle the churn in the team, and ensure that quality is not compromised. Giving people option to grow within the group, offer them option to go out of the group when you don’t have appropriate position for them to grow, all this was exciting. I consistently got good feedback through the 360 degree feedback process.

Vinay: What was challenging in talent management?

Yuva: I always thought myself as an introvert (focused on doing my work). So to move out of that space and learn to interact with people and then manage people were some of the key milestones in my professional career. These things made a big difference in transitioning me from a primarily academic oriented person to a professional technical leader. And in this context, handling people issues at an emotional level and professional level was challenging. Situation would typically be like this: Organization has priority changes, there is change in focus and I need to re-focus the group to deliver the best. So how to manage the low times and high times in a way that people are constantly motivated to deliver their best.

Vinay: In spite of you having natural talent to manage people, you moved to a role where people management is not a predominant part of your role. What was the driving force behind this shift?

Yuva: At certain stage in managing people, as things were in place, I started having significant amount of free time. During that time I started dabbling in architecture. I was creating some new software, started reading about different architectures and playing with it. Then I realized that just managing performance and communication was not giving me enough satisfaction. So a stage came where I could do management well but it was not exciting any more. This is when I asked myself “Which is the area I really enjoy myself working?” And “architecture” kind of popped in my mind. I spent significant amount of time researching about “quality attribute scenarios” and role of the process. I went through SAP sigma and now I am also certified SAP Sigma Black-Belt.

Vinay: Which year did you make this choice?

Yuva: When I took this decision, my overall experience with the organization was 8 years which included 4 years of management experience. I realized what interests me: innovation, strategy and architectures.

Vinay: What is your view on collaboration with academia and special interest groups in this kind of role?

Yuva: To be frank, this area of architecture has not been able to take firm root in India. Let me tell you an experience. There was this “Architecture World ‘07” conference where I presented on architecture issues with regards to quality of software. I went there and spoke about quality attribute scenarios and product lines. After some point in time I realized I was disconnecting with the audience. So I asked them “What is your problem?” So they said, “As architects we don’t have a choice. In 2 days we have to send the proposal”. In a service based organization, the importance of architecture for a solution is vastly undermined. So I would say the architect community within Bangalore is a disgruntled lot. I find it difficult to go and talk about new thoughts because they are so operationally tied down with the dissatisfaction they have today. So I find many forums gravitating to crib-sessions rather than forward looking thoughts. I personally believe there are very good people around. But I don’t know how to find them.

I work closely with SAP research group. SAP research has strong ties with excellent universities in the US and Europe. However, research work is far deep and has 10 year horizon. I still see disconnect between research lab and business group. This is what I am trying to do: Get a few ideas from SAP research, get a few ideas from the prototyping groups and help the requirements group and the architecture group.

Vinay: What will your advice “budding technical leaders”?


Yuva: I personally believe spending 5 to 6 years in an organization in a specific domain is a huge value add. It brings you the clarity about how to think in the domain, how to deliver. Jumping too often for 30% or 50% hike is good as long as you are able to manage the domain growth.

Chief Test Architect Yuva talks about architecture validation – Part 1

Brief bio:

2005-present Chief Test Architect, SAP Labs, India

2001-2005 Development Manager, SAP Labs, India

1996-2001 Developer, SAP Labs, India

1996 MSc (Engg), Computer Science & Automation, IISc, Bangalore

Yuvaraj Athur Raghuvir (also called Yuva) is a Chief Test Architect at SAP Labs, Bangalore. Yuva is a man of few words. However, you start talking to him about software architecture and he is all excited. In this 2-part interview Yuva shares his views about architecture validation, evolution of architect as a role in the Indian IT industry and his own transformation from a “hugely introverted academic person” to a “confident professional technical expert”. In this first part, Yuva talks about his current role and architecture validation through quality attribute scenarios. In the next part, we will see how Yuva’s career evolved and his movement from a “development manager” to “chief test architect” role. If you want to read about “architecture validation”, you can go here directly and to see how “architecture validation” works, go here.

Vinay: Please tell us about your current role

Yuva: Let me start with a bit of history. My current role is sequel to the role I performed for 2 years (05-06). The original role got created in the context when SAP wanted to get into partnership with an external partner for testing for NetWeaver product. During this time I was a development manager and was wondering what it means to improve testing strategy. Traditionally testing groups are very close to development groups. They understand what is happening and are good at testing even when the information is incomplete. What happens when you bring in an external group, you need to transfer the context of testing from the development group to the test execution group. To do this effectively, we defined 2 roles: Test architect and Test project lead. Test architect understands technology very well and has a basic development architecture background with an emphasis on testing. He is also a person who can elicit the requirements of testing better. Project lead is representing the execution group, what they would like to have and records the details.

Later, on closure of a pilot experience, a group of test architects was created across the globe. And I was responsible for leading the test architects primarily in coaching and delivering on this process of test context extraction.

Around the time this got stabilized, my boss asked me whether I have any methodology that evaluates architectures. That is when I started working on processes and methodology for evaluating architectures. Did lot of reading and found some methodologies which could work. In 2007, we had architecture definition cycle. Initially my ideas influenced the template structure of the document. From there, I moved onto the validation phase and eventually driving architecture validation cycles.

V: What is architecture validation?

Y: There are functional requirements and non-functional requirements. We are always focused on functional requirements. However, as the product matures non-functional requirements (like Safety, security, performance) are the ones which lead to customer satisfaction. These are also referred to as quality attributes. Now if you want to have security and high availability at the same point in time, then we hit a conflicting situation. Security means identity should be managed in the same location. High availability means you need to have redundancy. So you need to do trade-off analysis. When you make a trade-off decision, you are defining the architecture of the system.

So the latest thought is that the architecture is the enabler of quality attributes and it manages the trade-offs among various quality attributes and realizes it as a software structure. So architecture validation is same as validating trade-off decisions. And how does it manifest itself? By the end-user perspective. If you think about what is called “Quality attribute scenario” which takes you from the point where stimulus is given to the response and measure the system response. Then you have end-to-end definition of what a quality attribute scenario is. That gives you a fair picture as to whether the architecture is able to meet your system requirements.

V: Is this similar to what Clemens and Co have done?

Y: Yes, this is largely from the work done at SEI. We have had a closer look into this, taken another set of writing from Charlie Alfred to understand how to make the process repeatable across the organization. This is a fundamental change and will take time to get wide acceptance. So, we are working on some pilots in our organization with plans of getting more pilots in the future to understand and apply the methodology in a consistent way.

V: Tricky point is measurability of these quality attributes and percolating them down to sub-system. What is your view on this?

Y: This is certainly relevant in layered architectures and multi-component systems. There is another idea in this direction which is about product line architectures. Here you think about architecture in conjunction with production and quality. Now, one strategy to manage this flow down of the quality attributes is to envision the entire production landscape as a product line. And then think about where the re-use is maximum and there you focus on very high quality requirements. And where the re-use is less, you focus on different level of quality requirements.

V: Can you give an example of high re-use and low re-use?

Y: Typically any framework based system will have logging, tracing, exception handling, identify management, app server etc. These are highly re-used components. These become core assets of your product line. Quality requirements on these become very high.

Coming back to your earlier question: Without the product line architecture, how do you manage the flow down of quality attributes through your network? This is an area we are working on. What we are trying to do is to influence the structure of the architecture document in such a way so that we can identify pair-wise linkages or relationships at the architecture level and assign quality attributes to those linkages. As a provider of software and generic services, the prioritization of where the quality should be focused on is missing today. Going from a component to pair-wise relationship is probably the first step by which we can manage the flow-down in an effective way.

V: How does the architecture validation work?

Y: In the architecture document, quality attribute scenarios are specified. These scenarios are translated into test cases in the monitoring system. Then you define what is called a “landing strip” which says at which point of you development how much of your quality attribute scenario can you accomplish and the response measure on executing the scenario. The interesting thing about this is that architect is being made progressively more responsible for what you create. We used to have a situation where the architecture document after the review was not referred and we lost the traceability. This entire system allows you to do architecture traceability.