Mergers and Acquisitions, Inc.

David and I have both had the unique opportunity to be at organizations that were gobbled up by bigger organizations. When we were at MDL (www.mdl.com is currently owned by a squatter. Sad) we were purchased by Reed Elsevier (now called RELX Group. Weird.) and operated mostly independently until Reed Elsevier spun us off and sold us to Symyx (www.symyx.com redirects to www.accelrys.com which displays a company called BioVia. Karma.). The Symyx acquisition was pretty horrible, IMO. There is still a bad taste in my mouth over that one. I left Symyx shortly after the acquisition for WatchGuard, and David stayed on for a while until he was laid off.

David and I have since been acquired again.  David’s company now belongs to IBM, and my company now belongs to HP. We both agree that we would’ve never guessed that we would be working for IBM and/or HP. The thought, even now, seems a bit preposterous. But there it is…we work for massive companies.

This is nothing new, and we all know it.  Companies grow one of three ways: they grow organically by increasing their customer base, they grow by acquiring a smaller company and it’s associated customers, or a combination of both. It stands to reason that the third option is where large companies want to be, but as you gain more and more customers, it becomes increasingly difficult to grow organically as the potential target customer numbers shrink.  Take Kleenex as an example…their product is so ubiquitous that it has become a noun, not just a brand. We even call non-branded facial tissue “Kleenex.” How many more customers can they possibly add at this point through organic growth (discounting the addition through the birth of new humans)?

If you are a large company and you want to grow beyond existing customer base, you diversify your product line to attract more/different customers, or to get existing customers to buy more of your stuff. This means either developing new stuff, or acquiring someone who already HAS developed new stuff.  In my experience, it is almost ALWAYS the latter that happens, especially in tech.

Now, in the best scenarios, the acquirer knows to leave well enough alone. After all, you acquired them BECAUSE they were already valuable, so why change them and impact their value? I agree that some cross-pollination has to occur, and that in some cases, there may be overlapping redundancies. But from a product perspective, the acquiree knows exactly how to make and sell their stuff, and they know how to do it better than the acquirer.

To be honest, I am still sorting out how I feel about being acquired, but I am doing this through the lense of my own personality. And I am an optimist. So I believe that it will work out well for me and for Aruba Networks (this is the part where you snort and call me “naive.” It’s okay, I can deal with it). So far, it looks like things are working out very well for David over at his gig as well. But our respective acquirers are following the rule laid out above.

Time will tell. It always does.

IT? Political? You must be joking.

So, I’m back.

Since my last post, I have made a career change to Aruba Networks, which has been acquired by HP. As a good corporate citizen, I must state that the opinions made in this blog are my own, and do not reflect the opinions or claims made by my company.

Are we good? Good.

By moving to Aruba, the customer size that I now support has increased dramatically. While at WatchGuard, my customers tended to be smaller and MUCH leaner from the IT perspective. This obviously makes for some harried/busy IT engineers, but on the plus side, I was almost always dealing with the implementer and decision maker, all in the same person. This made for a much easier work flow for both of us, even if it ultimately increased our work load.  I will someday write something about how work flow and work load aren’t conjoined twins.  But that’s a post for another time.

With Aruba, my customers tend to be larger organizations.  In larger organizations, the separation of duties becomes more distinct, and any technical implementation will touch many hands.  I am a firm believer in the idea of many eyes = shallow bugs, so I am not denigrating the idea of IT specialization or separation of duties.  I spent MANY years as part of an effective and collaborative IT team, and did not make decisions regarding infrastructure/security (my particular bailiwick) in a vacuum. I worked with intelligent and respected professionals across all IT disciplines. It was, by all definitions, a great gig.

What I have learned is that this is an increasingly exceptional circumstance.

In a significant number of the larger organizations that I support, I have found that the collaboration across disciplines in IT can be minimal or even adversarial.

Why?

Well, I could rabbit hole about human behavior, but this isn’t a psych blog, it’s a tech blog. I’m an engineer. Let’s fix it.

  • Let’s agree that we all want to do a good job. Our jobs enable lifestyle choices, and we LIKE our lifestyles (generally speaking). Yes, we all have agendas. But just because my agenda may be different than yours doesn’t necessarily mean we are working at cross purposes. The organization wins when we all understand our jobs and the value of our teammate’s job.
  • Respect your coworkers opinions, even if they are wrong. I’m reminded of a time when I shot my mouth off during an international SE meeting about how PoE works, and I was dead wrong. My good friend and coworker, Bill, came up to me afterwards and corrected me. He could’ve sacrificed me, but instead he gave me the chance to do it myself. So I did.
  • Get out of your ivory towers (I’m looking at you in particular, ISO’s).  There is absolutely no benefit in sequestering yourself “above the fray” of the day-to-day IT operations. It is important to take the long view, I agree. It is also important to get a high level view of how particular technical choices/decisions will impact the business. But you can’t live there and also be an effective and collaborative teammate. This behavior is harmful to the business, and makes you a difficult coworker.
  • Learn new things. Many of us have spent a significant amount of energy to get where we are today. For some, these positions can command a certain amount of respect. Respect is a nice feeling, I like it too. However, when we try to learn new things, we are often at the bottom of the food chain, and that can lead to the dreaded “Dumb Question.” The question that makes the expert, or even the laymen in that particular area, roll their eyes. We’ve all done it. My only advice here would be to not let fear stifle the broadening of your skillset. Ask the dumb question. I do it all the time…it’s liberating.
  • Make time for collaborative exercises. Too often IT teams only work together under crisis. Fix this. Even if your particular project only touches the server team tangentially, include them at the outset.  Windows admins are smart, too.

That’s it for tonight. Don’t want to stretch myself TOO much after such a long hiatus.