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

In my experience, there are 3 types of companies when it comes to recruiting practices.

Talent hunters: These were the most pleasant to work with but you have to have time on your side. These companies seem to be focused on getting good people in and then figure out what is the right role for you. Unless you are a person who is extremely bothered about what position/role you start with, these are the best targets for you. If your history is like me, if your company is growing, so will you. You will not be holding the same job for more than one year in such environments. My philosophy is not to be too worried about the starting role. Designation (level) may become important if the company has a philosophy of bands of compensation by level.

I came across 2 companies like that. One is a small company in the East coast. When I talked to the CEO, it was obvious he had no outstanding job requirement. But every conversation left both of us with the impression that there is a great potential for both of us. I eventually talked to almost all the leaders in the company and then the board of directors too. One of the advantages of keeping your mind open in a small company is that you are not seen as a threat by any of the existing leaders who might be worried that the new executive will replace him/her.

The second company is a large company in West coast which takes this process one step ahead. Their recruitment process is entirely designed to see if that person is a fit for the company. The secondary question is where. In my case, after 14 interviews, apparently they decided I belong to them. However, before I left them, I had also expressed my opinion that none of the groups that I talked to had a lot of interesting things for me. I was asked to come back and talk to other groups and help find out whether there are other interesting opportunities that will excite them and me. After another 12 interviews, I found something that excites me immensely and I feel I can contribute from day one.

These kinds of companies had the most innovative questions to ask too. My favorite – “So, Rajib, 25 years from now, when your daughter has a 5 year old child and he/she asks – Grandpa, tell me a story from your office – what story are you going to tell him/her”? I had to think for some time. But that night as I thought about my answer, I realized – Man, that was a great way of finding out what is relatively important to me and what is not – what kind of things leave an impression on me and what doesn’t – leading me to understand what is my internal value/belief system. Incidentally, what I remembered first was a Herculean effort put in by somebody against all odds – and my bets – and carried the day for a customer of ours. No point for guessing where that person is after he/she left our company. Yep, same company who was interviewing me!!

Job Fillers: By and large, this is the majority in the spectrum. This is your typical “need to fill a job” recruitment which is usually the result of an executive leaving or the company operations expanding. The aspect of interviewing that struck me most was the amount of stress put on experience. Lot more stress is given on matching the exact kind of application (sometimes down to the exact application), industry, type of companies etc. than an executive search should ever do, in my opinion.

In my philosophy, if you are looking for a lower level job, I can understand the need to seek exact matches. (Actually, even that, I am not totally comfortable with. If you are looking for a Java developer, I will absolutely look at a C++ person and judge the person’s intellect level, ability to learn and work ethics. I can teach him technology quickly). As you start going higher up, you should absolutely be looking at broader skills – not exactly what technology, industry, and application somebody has worked in. Here is a simple fact of life – if you are growing as a company, your business will change, your models will change, and your market will change. You want to get in leaders who can see such changes coming and can actually quickly learn and adapt. Don’t forget that Nokia started as a paper company (and then rubber!), Wipro started by selling soaps and Lou Gerstner knew nothing of hard drives when he came to IBM from Nabisco. Experience can give people data – but you want people who have grown judgment. And yes, it is much harder to interview for these things in one hour!

At the end of the day, the root cause of this issue is that in these companies, recruitment is not looked upon as a strategic tool. You have to keep a good pipeline of candidates. Good people are not going to fall from trees when you have a job opening. Nor will you have a good opening the day you meet a great person. If you have to fill a job in a hurry, you do what I experienced with these companies.

Unenlightened Ones: While I am quite sure these companies have a great strategy for themselves too when it comes to getting talent, they left me with the highest degree of frustration just by their lack of professionalism. Fortunately, I did not have to go thru a lot of them but each and every of the large offshore vendors from India (I went thru 4) fell in that category. I am very well connected in these companies and invariably the CEO or top guy discussions went very well. Then things fell in a hole. The pattern was eerily repeated.

First and foremost, whoever you are talking to is always looking to getting you in their group. When it was evident that there is nothing that fits, there was more effort put with more promises of glorious future of that group than to look out for the rest of the company.

Second, with the exception of one company, there were too many phone meetings that did not happen (one was set and missed 4 times!!!) or started way late. There were a lot of promises of getting back within a stipulated time – which needless to say did not happen either. In case you thought this was happening with high level candidates only, another person from my company who worked in my group (couple of levels lower) gave up after getting promises from one of these companies (where unfortunately, I had referred him to) to finish the interview process for over 4 months!

I have to add that some of the smaller offshore vendors from India came across far better in this regard. At least they were professional enough to say that there was no fit or compensation requirements cannot be met… etc.

One more unprofessional practice you may have to get used to is that many companies of the second category (Job Fillers) just simply don’t tell you after the interviews are over that your candidature just did not work out. Between 3 friends of mine and I who did the job searches in collaboration, we are still waiting to hear from about 8 companies (and we know that those posts have been already filled). About 3 months back, there was a half page article on this in Wall Street Journal. Evidently, this has become pretty common in US.

In any case, those are some of things that I saw. Once again, these are reflections of my experiences. Feel free to send me your comments/experiences.

I am in the process of (hopefully) concluding a job search for myself which started in the background about 6 months back but in right earnest about a month or two back. As a background, I am a senior executive who worked for 10 years in a leading software enterprise application company – running global product engineering and professional services – about 800 people across the world. Before that I worked for 4 years in the finance industry.

Here are my learnings. These are entirely based on my experience.

Executive search firms are highly ineffective. At the end of the day, executive search firms work for the company. They are measured on whether a job was filled rather than how many resumes they were able to find jobs for. In the last 6 months, I must have contacted over a dozen executive search firms – including the top 6. None of them came thru. The one executive firm that did put me up at an account is somebody I had not contacted – they found about me from somebody else. Part of their challenge is that I do not think they share the resumes within the company. While many claim to have databases – other than one firm who I saw truly share their resumes – when I talked to as many as 6 people from the same firm – they had not a clue that all of them were talking to a person who is already in their database. My suggestion is to keep your network of the exec search firms up but do not count at all on that. Additionally, I found that the exec firms often help in coming up with the job description and they use their own way of “filtering” people – not necessary wrong or unfair – but very different from what I would do as a practitioner.

Surprisingly, small search firms come thru. I had the best experience with the small boutique companies. Usually, they cannot put you thru to more than a couple of companies but they were able to put me thru to the highest level. They also seemed more hungry for the business. Two out of the top five prospects that I liked best were brought to me by small search firms.

Websites are a good start. Sites like 6figures.com, linkedin.com are a good start. Usually you will find some job descriptions that you may like. What was effective for me was to find out about the recruiting firm or the company from these sites and then I called them up. 50% of the time I was able to reach somebody and then when I explained who I am, was put to the highest level which resulted in a phone call and often interviews.

You will be surprised who will come thru for you … and who will not… When I spread the word around people senior to me with whom I had worked in the past that I am in the market, I was totally surprised who all came thru and who did not. A CMO of our company with whom I had very little – but not substantial interactions was very helpful – she not only got me a few good leads – she followed up on them too! On the other hand, people with whom I was pretty close – some even socially – were not effective/willing at all. Lesson is not to count on people who you think you can count on.

People who were in my division were most resourceful!! By and large, the most high quality leads that led to at least multiple rounds of talk with the company came from people who had worked in my division – in fact none of them were my direct reports except one. Three of the top 5 companies that I liked came from people who worked in my organization at some point of time. I have a habit of wishing people who have ever worked in my division on their birthdays (I put them in my diary). All three followed the same pattern – email wishing happy birthday – reply asking how are you doing – response saying great, I am in the job market – phone call/email asking would you be interested in our company – me asking what do you do? Can you put me thru to your CEO – and the rest followed very quickly!! Lesson for me – Keep up the good habit of the birthday wishes (it keeps your network renewed once every year at least).

VC network. I do not have a strong VC network but while talking to a few startups, I noticed that this network is very powerful. If VCs are impressed with you, their ability to place you in companies that they influence is very high. However, this is an observation more than an experience.

That’s all for today. Next time, I will talk about some of the good and not so good practices of the recruitment process itself that I learn from…

Rajib