Becoming a successful technical leader

Blog moved to a new location

2008-03-08T04:25:00.000-08:00

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

Top 5 challenges of budding technical leaders

2008-03-01T03:13:00.000-08:00

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

2008-02-24T01:47:00.000-08:00

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

2008-02-10T02:41:00.000-08:00

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:

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

2008-01-25T02:27:00.000-08:00

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

2008-01-19T05:58:00.000-08:00

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

2008-01-09T01:37:00.000-08:00

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.

Two Faces of “Moving Up The Value Chain” (MUTVC) Syndrome

2007-12-23T02:40:00.000-08:00

Face-1:

If you are an ICT (Information & Communication Technology) services company headquartered in India, chances are high that you want to “move up the value chain (MUTVC)”. Sometimes you will talk about solution accelerators, other times it will be building a consulting practice or you may be even developing products. In all likelihood “innovation” is one of the core values of your organization. If it is not there already, there is a good chance it will be added in your next value-vision workshop. As the Economic Times article titled “On Cruise Control” says: Today’s globalized businesses are caught in cat-and-mouse game between value and cost.

At this point, it is good to take a step back and see why this sudden fascination for “moving up the value chain (MUTVC)”. Headcount driven time-and-material model has worked well for the past decade and half. And you don’t undermine such a model easily. To quote Mr. Azim Premji from this interview in Knowledge@Wharton, “The mundane business is also extremely profitable. It has a tremendous annuity value, and you don't ignore businesses like that. For example, maintenance of software and hardware are tremendous annuity businesses. If you build strong efficiencies into execution, they make very good margins. It is like a yin-and-yang situation: How do you build these strong annuity businesses and at the same time build other businesses that will establish certain differentiators in the marketplace, so that your image as a partner takes on a different dimension? That is the question.”

As the Economic Times article points out, there are 3 main drivers today for MUTVC. 1) Higher expectations: Customers are no longer satisfied with cost and quality, they want more, speed, end-to-end ownership. 2) Talent shortage: Linearity of the model (for every 1 percent growth add 1 percept to headcount) is making it difficult to scale especially in the context of high attrition and rising salaries 3) New architectures: Emergence of architectures such as SOA (service oriented architecture) which is making building re-usable components a reality (also called solution accelerators).

The ET article concludes by saying that “IT companies will employ more domain experts as well as those who can understand both business and technology”.

Face-2

Scene-1: I am meeting a BU head along with his direct reportees (Director Engineering) and the topic is “Need for technical leadership in the BU”. We project the number of domain/technology specialists side by side the managers in the BU. There is 1 BU head, 4 Directors and 15 Program managers on one side. And there nobody at the same level as even the program managers on the other column. The question was: Do you really need anybody there? Suddenly there was chaos in the room and it was concluded by the directors “We don’t know what to do with such a senior technical person”.

Scene-2: I am meeting a service line head one-on-one in his office. He was excited about discussing technical leadership. At the end he said “Look, when I have a person with Rs.15 Lakh salary, (s)he is becoming an overhead for me. I don’t know how to convert his expertise into business”

For us to move up the value chain, we need to establish clarity about (a) how we will create higher value (b) how we capture an appropriate share of the additional value we create. Perhaps solution accelerators is part of the solution to (a) and for (b) as the ET article says, pricing will have to become more value-based than resource-based.

If you are passionate about something, make everything else secondary says Ashim Prasad

2007-12-19T09:03:00.000-08:00

As I mentioned in the last blog, apart from expressing my own views I would also like to present views of some of technical leaders in the industry. It is a pleasure to present one such conversation with a friend and ex-colleague of mine, Ashim Prasad who is currently working as Principal Systems Engineer at Aricent, Bangalore. Ashim is deeply passionate about building new stuff, concrete stuff and prototyping is his second nature. Hope you enjoy the conversation.

Brief bio:
May 2007 – present, Principal Systems Engineer, Aricent
2005-2006, Senior VP, Textual Analytics Solutions,
1998-2005, Technical Manager, Sasken Communication Technologies Limited
1996-1998, Engineer, Verifone
1994-1996, Engineer, ICIM
1994 B.Tech. IIT Bombay

Vinay: What is your current role?
Ashim: Current role has 4 parts: (1) Architecting products – This involves looking at architecture for new products as well as re-looking at existing products. You may have 2-3 different products architected differently at different point of time. I look at convergence points across these multiple products. (2) Technology tracking – It involves primarily standards tracking. Identify common trends. This becomes an input to Product Line Management (PLM). (3) Prototyping – new product ideas (4) Expertise building – This involves mentoring and training people.

Vinay: How will you describe your journey to this point?
Ashim: It was vague. It just happened. Started working from 94. Passion towards certain things started developing from 1999-2000. Before that it was like doing a job, earning money, whichever company gives better salary, join that. Work did not matter. Rather there was no passion.

Vinay: How did you discover your passion?
Ashim: I think passion was there. But it was not out. Self-realization was not there that this is what I like. Hence, for 6 years I was doing whatever came across. And suddenly, I realized that this is not what I want to do and I want to do product development. The feeling was “Have I crated anything?”, “No”, “Do I want to create something?”, “Yes”, “Do I want to create something which people want to use?” “Yes” “How do I do that?” so answer came clear and loud that I can’t do what I want in my existing role. So there was a need to change. Finally I came to a realization that I enjoy “creating”. Initially I was confident of this realization only 20-30% that this is really what I want to do. But I went ahead with that. Then it crystallized after 3 to 4 years.

Vinay: How did the passion manifest?
Ashim: I don’t remember the details. But it was during that time that various ideas started getting fixed in my mind that this is what I should be doing. Ideas with respect to domain that I like to work in, the kind of work I want to do.

Vinay: What kind of idea did you form at that time?
Ashim: Precisely the kind of work I am doing right now. i.e. playing an architect’s role.

Vinay: Then what happened?
Ashim: Then I took a change in my career. I was working in a services group in the organization. I decided to move to a products group within the organization. This was in 2000. I went there when there was no position left. The group head was still willing to take me but at a lower salary. So I took a 20% salary hit. So the career change came at a cost. But it helped me in the long run.
Initially there was not much responsibility assigned to me. But still I was in a company of people who shared similar passions. And soon an opportunity came as one person resigned in the group. This new opportunity was a mix of tech and delivery. This involved delivering entire software on a device. At the same time technically responsible for delivery.

Vinay: What do you mean “technically responsible”?
Ashim: It was more like a sub-system design. There was an architect who was responsible for system level architecture. I was responsible for the architecture of a sub-system.

Vinay: What happened next?
Ashim: I continued at sub-system level for about 4 years and then I started moving towards system level architecture. Again, I don’t think I planned it that way. It happened.

Vinay: What did moving from sub-system to system meant?
Ashim: You take into account the entire system and start looking at how it will be deployed. You start taking the resource view (e.g. memory/MIPS) for the entire system.

Vinay: What was the next move in your career?
Ashim: I got into a startup and subsequently started my own business and I did that for one and a half year. Roles in this phase involved doing system level design like in the earlier roles. However, it had an additional component of business attached.

Vinay: What was your learning in this phase?
Ashim: Biggest learning in the phase was this: When I used to do architecture or system design earlier, the business inputs were not considered important. In this phase I learnt that these inputs are the most critical ones.

Vinay: Can you give one example of such a technical decision?
Ashim: We were thinking of a couple of options for a solution which was targeted for retail automation. The 2 main options were (1) build you own device (2) use mobile phone. Building your own device would have meant clean architecture; and making the existing phone work means non-clean architecture and it also meant taking deviations from the specification of the solution. But we went ahead with the second option. Because that made more business sense rather than making your own device.

Vinay: What happened next?
Ashim: This phase lasted for one and half year. After that I decided to focus on technology (rather than business) for some more time. Of course, not loosing the learning that business understanding is critical. But having a primary responsibility for technical leadership.

Vinay: What were some of the exciting moments throughout your career?
Ashim: First one occurred after I shifted from services to products. It was the first launch of the product. This was internal launch (within the organization). However, seeing the entire thing working with plastic and everything integrated was an exciting experience. Second one was the plunge I took of doing my own business. There wasn’t any end result that was achieved. However, the journey was certainly enjoyable.

Vinay: What do you see as challenges in the current role?
Ashim: One challenge still remains is to get a buy-in from everyone for some of the technical decisions you take.

Vinay: What kind of approaches you take to overcome this challenge?
Ashim: One thing which I try to do is try to interact more with people who are really going to implement. Many points I am able to convey off the meeting rooms than in the meeting room (informally than formally). Till now, I have found convincing senior management easier.

Second challenge which I see is keeping track of multiple threads. When you are doing a system design, there are several threads running. For example, for building a phone, you need to take various decisions related to hardware, firmware, RTOS, JVM. These decisions are interdependent. You solve the interdependency between two of them, the third one conks off. Keeping track of all of them simultaneously is a challenge. I haven’t still figured out a better way. I go in an incremental manner. I am not able to handle more than 4 or 5 such threads at a time while in reality there may 10+ threads existing.

Vinay: What kind of advice you will give to people who are aspiring to be technical leaders?
Ashim: This is more of a general suggestion, not only for technical leaders. If you are passionate about something, go for it and make everything else secondary like salary, organization, which people you work with. If your primary goal is organization, then make it primary and make everything else secondary.

Disclaimer: Views expressed here are Ashim's personal and may not be representative of Aricent.

What is technical leadership?

2007-12-14T19:10:00.000-08:00

Welcome to this blog on technical leadership!

It has been 9 months since I started conducting 1-day workshop on “Becoming a successful technical leader”. Over 150 budding technical leaders from 10 technology organizations (all based in Bangalore) have participated in this workshop. Information about the workshop can be found here.

During the workshop, we discuss various topics related to technical leadership mostly in the context of the technology industry in India. For example, why do we need technical leaders? Do we really need them at this point? What should be the role of such people in services industry? What should a technical leader be doing in a products company? And so on. I end up meeting various stakeholders like senior managers (including Chief Technology/Development Officers), project managers and technical leaders. I intend to use this blog to express my own ideas on this topic as well as publish conversations I have with various stakeholders.

In this article, we will look at various connotations of the term “Technical leader”. I have come across following usages:

1. Person with designation “technical leader”
2. Person leading or managing technical people
3. Person on technical career ladder (known as tech-ladder)
4. Person who carries a personal technical brand

I guess all the usages are relevant in their contexts and they are overlapping in their meaning. For example, most of the time, a person with designation “technical leader” is also a person who is managing technical people. Similarly, a person on technical ladder is also the one who carries a personal technical brand. However, if I were to choose one defining characteristic of a technical leader, I would choose the last one: i.e. the one who carries personal technical brand.

What is a personal technical brand? It is your ability to influence a bunch people with your technical expertise. These people may or may not be reporting to you. This is where it differs from what is called “span of control” (people directly or indirectly reporting to you). Many times personal brand goes beyond the organization. We will discuss this in more detail in the subsequent articles.