If you have been a manager of managers, undoubtedly one of the things that would have frustrated you is how so many of your managers who had an otherwise perfect record were woefully lacking in people management. The pattern has repeated like clockwork in my life.

This has prevented numerous ambitious managers from moving forward in their careers and often has frustrated them immensely. (Don’t count on the latter though. Most managers far overestimate their organizational and people skills). I am not talking about managers who “are liked by people”. While this can be a charismatic leader, often people “liking” has little to do with a manager’s effectiveness with their organization.

I am talking of a manager’s ability to get the most out of individuals and the organization in a way that is profitable for both the company and the individual. I am talking about a manager’s ability to keep the organization continuously hungry to scale greater heights. I am talking about a manager’s ability to deliver 5X results compared with similar sized teams. (In the IT industry as well as many others, this is absolutely achievable)

There are various books written on how to become a great people manager and such other topics. Given the number of books written on this subject, I suspect this is not a commonly agreed upon topic!! I shall try not to add to that literature base.

However, what I am going to narrate to you is what I believe is the fundamental reason why so many bright managers who manage just about every aspect of their business very well, find it difficult to get the people management aspect straightened out.

What makes people management so different from other streams of management?

At the core of the difference is standardization versus differentiation.

Pick up your MBA courses or the millions of books written on management – be it production management, development management, sales management whatever. The focus is always to derive higher gains by running it as a well-defined process. The general theme is very simple – look at the processes, standardize the processes, set in the measures and then drive higher goals through those measures and exception management whenever there are variations to those standardized processes.

That is how Ford drove how to manufacture cars. That is how companies like Siebel and salesforce.com have made money – by helping to standardize the sales process. That is how developers have increased product quality – standardized development process.

You don’t make one car fundamentally different from the next on the assembly line. You try not to make every sales deal a Picasso (unique creation). You follow the same steps to write the next line of code as you did for the previous one.

However, this management upbringing falls completely flat while dealing with people. Each person truly is very different from the other. They need and demand very different kind of treatment. They respond to different kind of stimuli. Given two machines, you will roughly follow the same steps to get 30% more productivity. Try that on two employees sitting next to each other and you will quickly realize the futility.

The art of differentiating makes or breaks a good people manager. The method of “standardize-measure-manage” will not work here. Good people management takes far more time. The best people managers try to find the right buttons for different employees and figure out how to challenge each one of them while keeping them focused on the corporate goals.

Any “broad brushing” of people issues usually has a very limited effect. I am sure you are aware of what kind of exciting responses you get from your employees when you talk of HR Policies. I suspect it is this “one-size-will-fit-all” approach that they roll their eyes for. As individuals, they demand individual attention and micro-plans/policies. (I am not saying all of them are justified).

Next time, you are facing a personnel issue or are drafting something of that nature, take a step back and give this a thought.

Rajib Roy

In my experience, organizations have a tendency to dwell on the negatives. How many coffee bar discussions have you run into or have been part of – where the basic theme was “why we are not doing things right” or “why this manager / executive is totally screwed up”? Surely many more than the ones which talk about the company wins or what the organizations are doing right.

As I think back on this, there are three things I believe I have learnt…

1. Negative news travels much faster than positive news: Have you seen how sales “loss” stories are known by more people faster than the “win” stories? How some negative press about your company is on more desktops of your employees than positive press? You would think there is almost a salacious side to all of us that focuses on the “gossipy” side of events for this to happen. Organizations behave as if negative news is more “urgent” than positive news.

2. “My self-worth is tied to how I can prove others are screwed up”: I believe when people – in a work as well as a social environment – engage in pointing out how and why things are screwed up, there is an inherent human psychology working that is trying to portray that “I know better”. I also believe that there is a side of us that is convinced that others will think that we “know more” if we can show the imperfections than if we talk about the perfections.

3. Positive people have a remarkable effect: Although rare, I have indeed come across people who can always see the brighter side of things. Who can focus on the things that are going right. And I am not talking about “spin” marketing. Though such leaders are few and far between, people tend to agree that such people are “better” leaders than your run of the mill ones.

This is probably a great pointer to many of us who aspire to become great leaders some day and leave a mark in this world. I loved it the way Colin Powell put it – “Perpetual optimism is a force multiplier”. My personal experience has been that it takes time to get organizations to share your level of optimism. But you can do that by being sincere, acknowledging that there is work to be done but repeatedly focusing on the wins. Once you do that, organizations grow a natural tendency to follow you as a leader.

In a previous environment that I worked, where we were clearly losing path as a company, it was remarkable to note how the “optimistic” leadership statements, while bought by rank and file initially, was quickly seen to be spin and insincere since that is exactly what they were. Ever since, I am convinced, that as a leader, you first establish your sincerity – then focus on the positives. That is an amazing combination that can energize organizations. The “can do” attitude is very infectious. Once the leader exudes it, the whole organization exudes it.

I would like to end by quoting from Colin Powell again which best articulates my theory on this topic…

The ripple effect of a leader’s enthusiasm and optimism is awesome. So is the impact of cynicism and pessimism. Leaders who whine and blame engender those same behaviors among their colleagues. I am not talking about stoically accepting organizational stupidity and performance incompetence with a “what, me worry?” smile. I am talking about a gung-ho attitude that says “we can change things here, we can achieve awesome goals, we can be the best.” Spare me the grim litany of the “realist,” give me the unrealistic aspirations of the optimist any day.

Please let me know if you have any thoughts on this. Or what your experience has been.

Rajib

If you have been selling enterprise software in the last five years, you have undoubtedly gone thru the following scenario multiple times. You did everything that you know you should do – you have put in a perfect value proposition, your software scored most points in a bake off with other competitors – you even got a off the record assurance from the business users that yours is the software they will recommend. And yet you lose the deal – sometimes to the ERP vendor and increasingly to a decision to make a home grown solution.

Whatever happened? After interacting with scores of CIOs in some of the largest companies in the world, this is what I have distilled in my mind…

The shift of power to the CIO

Ever since the internet bubble burst, as organizations have realized that they went overboard in buying packaged applications (most of which could not be implemented due to want of implementation funds and time), there is a subtle shift in power that has happened in this buying process. And that is the emergence of the CIO as the more powerful decision maker. It used to be the business side of the house. But that underwent a change.

Don’t be fooled into thinking that business value of a solution lost its utility. It absolutely remains a driver. Contrary to popular belief, CIOs are totally aligned with the business folks in extracting business value from their investments. However, a second driver has emerged as a decisive factor in many of these decisions – and that is the Total Cost of Ownership (TCO).

TCO includes not just the license cost of buying the application but also the cost of implementing it, integrating it, writing code to extract data and massage them and then more importantly, maintaining all this over the years.

And here is where the whole charm of best-of-breed application vendors starts falling down. While a lot of software has been written in the last 15 years solving some business problem very elegantly, very little has been done, in what I have seen, to solve the CIO’s problem. A typical supply chain product implementation across the industry as an example usually had the following breakup – for every $ that you spend on license software, you will spend anywhere from 30 to 50 cents on hardware and other middleware, anywhere between $4 to $10 on professional services (to configure, implement, integrate etc), and another 1 $ over the next 5 year or so for annual maintenance.

Add to that the cost of upgrading the software (application vendors will invariably ask you to upgrade once every 3-4 years and these are not simple technical upgrades of putting the CD in and pressing some buttons here and there) and the cost of the internal people or external contractors who are involved in the long term maintenance of the implementation code written. Now you get an idea what makes the CIO cringe even though you are asking for just a $ of product to be bought.

This is where broad providers like ERP vendors win. They may not have the best and most elegant solution – but their “good enough” solutions are very attractive since that avoids a lot of the integration and data manipulating costs (the story at least from the ERP vendors is that the new modules work perfectly on top of the old data models). Maintenance is far less of a cost and there is one less vendor/provider to deal with for the CIO. If you read a previous blog I had written about mergers, you will realize that it is the same driver – focus on total cost of ownership – that made the winning mergers rewrite the acquired software all over again with their existing architectures and data models.

The re-emergence of home-grown software

The swing towards the home-grown software is occurring ever since three things have come together. First, as I explained, the cost of making a best of breed solution sit on a pre-existing IT environment is high. But the fun starts after you have decided to spend that money. No pre-packaged software ever solves all the business needs and requirements that you have. (That is the nature of the business – it is not necessarily the fault of the application vendor). However, for you to get those features built in, you are asked to stand in a queue of other customers and follow the product release deadlines that the vendor has.

While vendors are absolutely eager to help you and see how to expedite things, there is no guarantee that your feature will be put in. The vendor is in the business of making standard products and will always prioritize “commonly asked for” features higher than the rest. (Don’t forget the sales and competitive pressures R&D organizations go thru also – their internal sales/executives saying “have to have this feature else we will lose the deal”!!). From the CIO’s point of view, he can’t care less about all the plethora of features that he never uses. He just wants his stuff – his way and that’s all he is asking for.

Second, as the budget of the CIO kept getting squeezed over the last five years, the ratio of money spent on “new projects” has been going down. A CIO divides his/her budget roughly into two parts – the ongoing maintenance of existing systems and then “new” projects. Pre-2000, the new projects could command as high as 25 to 30% of the total budget. Over time, that has been squeezed down to sometimes as low as single digit of percentage. Think of ongoing maintenance cost as almost fixed cost. And as budgets got squeezed beyond those levels, the CIOs started adopting the India model whole scale since that brought down their maintenance side of the budget by about 30% on an average.

However, the business demands did not sit tight just because budgets were being cut down. If anything the landscape became even more competitive and customers were less tolerant of service levels being missed. In this world, the CIOs started looking into the possibility of harvesting their existing investments. Technologies like web services have made it much easier to leave the existing code as is and put wrappers around and use these existing functionalities in workflows that you can build outside these code bases. These are usually called composite apps. The theory is – as I said above – you put in wrappers over your legacy code to expose the functionality as web services. And you can write composite apps that use these web services and any new ones that you write to solve a business problem. You leverage the existing data models as well as functionality.

Finally, the emergence of quality labor at a fraction of a price from the India vendors has made it much easier for the CIOs to attempt to build these solutions themselves. And some of the CIOs have gone to the extent of opening up their operations in India themselves (almost without exception, given the market of India, these companies have some sales presence and a legal vehicle already existing in India). Opening up your operations gets you further cost advantage (almost 1:4) but on the other hand you take on some of the management problems on yourself.

In any case, hope this helps you understand what goes thru a CIO’s mind. Hope this will help you in steering your company strategy on how to build solutions. In the least, you will know how to give a good sense of where your products are on the TCO front to the CIO.

Rajib

Have you ever wondered why certain companies have extremely loyal band of employees and some do not? I am not talking of people who continue to work in an environment due to sheer inertia and the inherent human inclination to avoid a change. I am talking about those set of people who work with maniacal ferocity towards a vision often against large or at least better placed competitors. What makes them drink the “Kool Aid”? What gets them the mantra?

What is that the leaders of these companies do? Without exception, these employees consider their leaders to be charismatic. What is charisma? And how does one achieve it? Is it purely a personality thing?

Sometime back, I was doing some research on what makes organizations last very long. Most companies die out before reaching double digits of age. I think it is worthwhile to study the parallels in how these employees behave with some very long standing organizations. The three longest standing organizations that I can think of are (i) the army (ii) the church and (ii) universities. Their longevity has run from 200 to 2000 years. Only half a dozen of corporate organizations can come close to even 200 years of age.

I will take a parallel from the army to explain the loyalty of employees. Why would any logical-minded soldier rush up a hill under heavy machine fire with incredible personal peril? Similarly, why would anybody not revoke their religious beliefs even under the severest torture? Why do employees work for a small company where the odds are against its survival?

There are three conditions that need to come together for the above to happen.

(*) A soldier needs to have tremendous belief in the commander that he is asking them to charge the right hill.

(*) A soldier needs to believe that, with enough sacrifice, the hill can be conquered.

(*) A soldier needs to believe that they have the “moral” right to win the hill.

Thus in companies where you see the maniacally loyal employees working towards a “great cause” invariably have the following things…

(*) The leader has painted a great vision – a vision that surpasses Wall Street expectation of mere fiscal pressures – a vision that shows why the world will be a far better place to live in – a world you would like to leave for your children if you achieve your vision. The leader exudes confidence in explaining to the employees why that is the “right” hill to charge up.

(*) The leader has impressed upon the employees that the only difference between the winner and the losers is execution. It is hard work. It is a success that is built upon a lot of sacrifice from the employees and their families. The leader acknowledges the sacrifice and thanks them for that. But also maintains that there is no short cut to success. Is quick to articulate why he believes he has the best “soldiers” too. What makes his employees different from other employees?

(*) The leader impresses upon his employees why it is their moral right to win the war. How they have the best vision. How the world is served best with their view of world order. How they focus on the right things which supersede small elements of focus like quarterly profits which is the sole focus of the competitors. How the competitors are busy make money for themselves while they want to make money for their customers.

That is the essence of what I have concluded…

Please let me know if you have any thoughts on this. Or what your experience has been.

During my last stint of 10 years in an enterprise application company, I was fortunate enough to see many mergers and acquisitions as we grew (over a dozen). The acquisitions ranged from very small companies in far flung places like Scandinavia to the largest software acquisition (of that time).

The lessons that I learnt are the following:

Things always look great from outside. Almost always things were much more hairy than was visible before the acquisition. Be aware that somebody who is willing to be sold out would for very obvious reasons put their best foot forward. There are more stories than you would care to hear in my previous company where we had everybody involved in the acquisition swearing by the greatness of the company to be acquired and without exception, each one of them turned out to be disasters. That does not mean the executives and team members were not intelligent (although I will admit they were more impressionable than other others – I think that happens in young software companies especially if they do not have a healthy ratio of seasoned executives brought in from outside). What it says is that take all your time to do the due diligence. Assume that 50% of your conclusions are wrong. Then seek data to disprove that hypothesis.

Be clear about what you are acquiring for. Are you focused on acquiring the customers? Make sure that you do not lose the key people who have the customer relationships (which often is not the sales or account executive). Are you focused on increasing your footprint by acquiring IP? If so, read the next point.

You cannot integrate yourself to greatness This is perhaps the greatest learning I had. As one of my peers once summarized it best – When you buy IP, it is in the people not the software. Without exception, we followed the software route. Which means we tried to “integrate” all these products into one set of solutions? The nightmare was unbelievably costly and is what I believe eventually brought us to our knees. You are much better off taking the hit of isolating top 30% of the acquired company’s engineering group aside and tell them to rebuild the solution on your existing architecture all over again.

Don’t worry about which is the better architecture. In almost all cases, it is like debating over religion. Technology is way over-rated for most enterprise problems that customers face. You will much faster to market with a truly integrated solution with lesser overall cost (for both you and your customers) of ownership by taking the hit upfront. I admit it takes guts to do this. The whole world is expecting to show you results from the merger. But companies like Siebel, Cisco have this model outrageously successful.

I would like to reflect on the only successful merger we had. The big difference I see from the other mergers is that we had some amount of history with this company. We used to resell their product for about a year. I think that gave us a great due diligence. We understood what was working and not working in positioning this product to our customers and what the difficulties the customers were having with the product were. What we did not do is the point number 3 above and I have paid heavily for it!

Feel free to send me comments about your experience.

During my job search, one of the questions I often got from prospective employers – especially VC firms was – can you help us reduce development costs by offshoring to India? For most of them, I advised to exercise caution. It was not the right time for all of them. Here I will write down my learning from offshoring work to India.

This is based on my personal experience of having offshored work to my India organization for the last 8 years. The peak size of my team there was around 250 in product development and 350 in services. Other than this, I had about 100 partner resources working in India too. China and Hungary were the two other offshore centers (although much smaller in size) that I had. (Rest of my team and I were based out of US).

What I am very impressed by is the quality of people in India. My experience there (as well as in China and Hungary) is that there is a huge supply of highly intelligent people. They are typically very hard working. The work culture seems to be oriented towards putting in long hours. With the proper guidance and leadership, and a little encouragement, they have moved mountains for me. All this at about one-fourth my cost basis (compared to US).

Two different types of work

Having said that, I need to add that I saw great success with one kind of work and only mixed results with another. Let me explain the two different types of software work that I have seen in all companies. First you have the project oriented development. These are typically turnkey projects. Requirements are nailed down upfront once and for all. And as changes happen to the requirements, you have a rigorous change management process to deal with extra money and time. After the development is over and the software is “live”, usually, it gets into maintenance mode with small incremental changes over time. Most importantly, such software is targeted for one customer and typically one target IT environment (operating system, database, UI technology etc.).

I have found that India is very good in this. For the last 35 or so years of offshoring experience that India has gathered has been almost entirely in these kind of turnkey projects (if you take out the body-shopping aspect of the industry). Which is why, Indian companies have been in the forefront of adopting project-oriented processes like SEI CMM models and such.

The second kind of software work is product oriented development. This is where you have a “continuously” worked-on piece of software. There is no one big completion date and then ongoing maintenance model. Typically you have many completion dates (called releases). And there is no final list of requirements. Through the life of the product as the market and customers evolve, new requirements are generated. You don’t budget the activity as a project. Instead, typically, you have a fixed capacity to deal with – and now you figure out how to prioritize your requirements to fit the next release capacity. All software product companies have this model.

I am rather unexcited by my experience with India on this front. Since this is where most of my learning was, let’s try to understand why IT companies in India don’t excel (yet) in this. Before I get into that, I must hasten to add that there were 2 companies – both very small – who absolutely stood out in their ability to understand and deliver to the product oriented development. And I had the opportunity to partner with them both. But that is 2 out of probably 100 companies that I have had the chance to interact with.

What explains the difference?

First and foremost, the nature of work is very different in the two models. In the project oriented environment – typically a lot of things are spelt out and the development engine in India is focused on “doing it”. You basically code to the customer’s stated requirements. But if you are writing a product, you have to think a lot more. Good software architects become good not by designing to a requirement but being able to think thru what else might be required in the future and therefore design today such that anticipated future requirements can be put in easily. You don’t get a chance to say – “None of my older customers had required this – now I have to totally redesign the architecture”. This means the key developers need to be much smarter and more importantly understand business domain. Most of the people I have interacted with in India – are great developers – but not what I am talking about here.

And that is not all. Remember, we talked about the target environments? When you are writing a product, you have to design it such that it can work with multiple languages (think double byting), on multiple platforms and multiple middleware choices. That requires far higher level of abstraction in your thinking and design. That is not the experience typically people have in India.

Finally, don’t forget the people angle. India (like China, Japan and other countries in Asia) has a background of hierarchical society. The social ethos of what is important and what is not important is very different from what you may be used to in the US. Typically, for any average person, being a “manager” is the immediate goal in India. After that is “how many people report to me”. Being a country with a very large population and much fewer resources, the DNA is built in the people to be very competitive and fight hard to rise up the hierarchy. Most of the software developers I have interacted in US don’t want to be managers – often have a healthy level of cynicism towards them – think Dilbert! In India therefore, it is very difficult to have people work on the same piece of code year after year. Their career motivation continuously makes them look for a “development manager” job or move to offshore services work to be a “project manager” or even better international assignments. Being a great architect is hardly ever a career goal for them – and I do not blame them for it – given what their peers, market and society values. (Just look at the compensation numbers between the top technology person and the manager in any team). On the other hand, how can you be good product developers developing great products if you don’t stick to the code for a long time and have the knowledge and history of why certain design decisions were made?

What can I offshore then?

First, you should not pass up on the opportunity to leverage the great tool offshoring is. The price arbitrage and quality of people is too high not to think about it. Just make sure you are offshoring the right parts of your operations, though. While the cost difference is great, there is additional cost you take in terms of more rigidity in process of communication and handoff between teams separated by a couple of oceans, training costs, attrition (and therefore re-training) and the like. Do not focus on how many dollars you are spending in either scenario – focus on what will you get for a dollar. “n” people in a team often outperform “4n” people in another team – especially as “n” tends to be smaller. (4 represents the cost multiple).

Look at which aspects of your software development are more commoditized than others. If you are a typical enterprise software development company, start with the services side. Your usual customer implementations exhibit all the characteristics of a project based execution. Requirements are nailed down early on; you typically have a “go live” date and then move on to maintenance. There are a large part of this work (especially between post-requirements and customer site testing phase), that can easily be packaged and moved. As an example, a lot of custom development, data work, model building work, testing work can be easily done from India.

If you are a services company, obviously, this is a no-brainer. I suspect you are under enough price pressure and customer pressure that you are doing this already.

For the software development teams, I strongly advocate against doing this till you are about 15 people (development team) strong or so. After that, you start looking at those parts of the work which are easier to package, are reasonably commoditized, and can be managed even if the team members change every 2 years or so. Examples of these are bug-fixing teams, internationalization teams, quality testing teams etc. Also, if you have a long list of nice-to-have features which need smaller changes but you never get a chance to prioritize them high enough – they would be a good candidate too. It is very important to point out here that it is highly desirable to ensure that you have a source code control system and regression testing framework that can work across multiple sites – or else you are going to have a lot of fun merging work of multiple teams and then coming up with errors too late in the game.

After you have reached a size of 30 or so, you should think a little more ambitiously. If you have a portfolio of products, pick out the ones that have reached reasonable amount of maturity and most of the development are incremental development. If you have one product, identify the modules that don’t need a lot of understanding of domain or day to day handholding – e.g. framework layers. Finally, if you are thinking of doing next version (new architecture – not next release) of products, move the old product to India and do all the new product in one location (even if you bring people from outside) rather than trying to do some part of the development from offshore from the very beginning. I saw a few teams succeed with this model (right from the beginning split work between India and US) but my opinion is it has been a far more costly and slow.

In essence, the size of the team and the nature of the work will drive your decision.

Those were my learnings. Feel free to add in your comments or learnings…

Rajib