All Posts in Process Management and Improvement

|In: Career Management|Last Updated:

For employees, a merger or acquisition is a lot like The Brady Bunch:

  • In The Brady Bunch, the kids had to get used to a new parent having authority. In a merger or acquisition, managers from the other company now have authority.
  • In The Brady Bunch, kids who didn’t used to be brothers and sisters were suddenly siblings. In a merger or acquisition, people who used to be competitors are now fellow employees.
  • Every household has its ways of doing things. In The Brady Bunch everyone had to figure out the ways of doing things for the new, combined household. In a merger or acquisition, the unwritten rules of how things get done around here aren’t the unwritten rules any more. Or else they are, but just for employees of one of the two companies involved.
  • In The Brady Bunch, a laugh track told everyone what was supposed to be funny, even when it wasn’t. In a merger or acquisition, employees are supposed to pretend everything is great even when it isn’t.

Okay, it’s a reach. You try coming up with a brilliant lead every week. It’s a lot like having to write a new sitcom script … oh, never mind.

When it comes to mergers and acquisitions, the easiest approach is to operate a holding company, as was mentioned last week. In the extreme case this looks a lot like a mutual fund: The parent company owns a portfolio of businesses, which it mostly leaves alone.

Warren Buffet’s Berkshire Hathaway operates like this. It works. It just isn’t very interesting. In Brady terms, it’s sort of like the backstory of when Mike Brady and Carol Tyler were dating — the Bradys and Tylers were separate households, with all that implies (or implied in the late 1960s and early ’70s).

So let’s skip that part and go to the sort of merger or acquisition that serves a strategic, competitive purpose — one that fills out a product line, provides access to a new set of customers, adds production capacity … that sort of thing. What factors, beyond the usual textbook stuff, determine the success or failure of this sort of merger or acquisition?

One of the most important is both the easiest to understand and the hardest to accomplish: Changing what “we” means. Interestingly enough, the better-led the pre-M&A company, the harder this is.

In companies with excellent leadership, employees feel a strong sense of attachment to their employer. They have an equally strong sense that they personally own the company’s brand, defined as the expectation customers have regarding what it’s like to do business with the company in question.

Imagine a fine company like this … being brand mavens we’ll give it the snappy name Tyler, Inc. … is acquired by the marketplace behemoth The Brady Company.

Brady being what it is, and this being an acquisition, the combined businesses will retain the Brady monicker. Think Tyler’s employees will celebrate their new corporate affiliation?

Of course not. Their loyalty is to the Tyler brand. They identify with it. They live it. And it isn’t the same brand that Brady has — a difference that goes well beyond the name change.

See, Tyler prided itself in the tailored, customized service it gave all of its customers. It encouraged its employees to innovate — to improvise if that’s what made the most sense, so long as the result was something the customer in question would value, and so long as it was profitable, too.

That was the essence of Tyler’s brand, and its customers were happy to pay a premium price for the they-take-great-care-of-me sense of security that went with it.

Brady, in contrast, is all about finely tuned, highly efficient processes built to support standardized products and services. It also encourages employees to innovate — it has an Innovation Committee, in fact, to which its employees are encouraged to submit their ideas, which the IC screens, assesses, ranks, and prioritizes in its quarterly Innovation Planning Meetings.

Think the Tylers will all be happy about becoming Bradys? Of course not.

The sad thing about our mythical scenario is that Brady’s executives acquired Tyler specifically to gain its ability to provide premium service to its customers. What they haven’t done is figure out how exactly they’re going to accomplish this within their signature high-efficiency, product/service standardization practices.

And it gets worse as we look beyond the executive suite, because with increasing distance from the whole point of the acquisition comes an entirely natural attitude:

“We bought them, so of course they have to adapt to our way of doing things.”

* * *

In case you have a suspicious nature and think I’m writing about Dell’s coming acquisition of EMC, or NTT DATA’s coming acquisition of Dell Services, nothing could be further from the truth.

Among the reasons: I have no involvement in the former and as far as the latter is concerned I’m just a passenger on that train — I don’t know anything more about either transaction than you do.

Comments

|In: App Dev Methodologies|Last Updated:

Why have Agile methodologies (including DevOps, which adds agile deployment to Agile development) made such inroads in IT? Why is OODA (observe, orient, decide, act) so important for business strategists?

Agile/DevOps is OODA applied to application development; OODA depends on business agility, applying many of its core concepts to external threats and opportunities.

It starts with the gunnery problem. In case you aren’t familiar with it …

You’re shipboard. You man an anti-aircraft gun. The shells you fire have an initial muzzle velocity of around 2,500 feet per second, decelerating due to gravity as they ascend toward the aircraft you’re shooting at.

The aircraft is a bomber. It flies at something less than 1,000 feet per second. Being a math whiz you can project exactly where the bomber will be when your shell reaches its altitude, allowing you to aim at the exact spot in the bomber’s trajectory where your shell and the bomber would attempt to occupy the same space at the same time.

But, the bomber is piloted by someone who, all things considered, would prefer that their aircraft’s trajectory and that of your shell don’t intersect, and so they don’t just fly in a straight line.

In application development terms, by the time your shell reaches the target’s altitude, the requirements will have changed.

Why Agile? So IT can deliver the software needed to support business changes (where you aim) in time for the planned change to still be relevant to the business’s new situation (before changes in the bomber’s flight path make your aim wrong).

Why OODA? Same answer: The attacking plane is a competitor, or the overall marketplace, or some important change in circumstances that will affect your business.

Your planned actions have to still be relevant when they “reach the attacker’s altitude” … when the changes you anticipate become real, recognizing that the more time that elapses the less predictable the future (the bomber’s position) is.

See, there’s a reason we’ve settled on the term “Agile” instead of “Fast,” which is that depending on what you mean by “fast,” waterfall is much faster than Agile, as was pointed out a few months ago in this space. It’s faster in that, assuming you have a useful way to measure software functionality, waterfall generally delivers more of it in a unit of time than Agile or DevOps.

But, waterfall delivers it all at the end of a long trajectory, during which business circumstances might change and change again. Waterfall design and development have a lot in common with a gunner shooting a slow, heavy shell that packs a lot of explosives at the spot a bomber would be in were it to continue flying in a straight line.

It’s a big bang that misses the target: Waterfall’s fixed requirements and specifications and need to develop and deliver the whole system in one piece conspire to deliver results that are largely irrelevant when delivered.

Pushing the analogy to the limits, Agile, and even more so DevOps, is less like a shell than a surface-to-air missile. They’re able to track changes to the target’s trajectory and adjust course accordingly.

Waterfall still has its adherents. Their near-universal explanation of waterfall’s high failure rate is that business people “don’t know what they want,” which presupposes there’s a way for them to know the answer to the question, “What do you want the software to do?”

Someone once studied people who design and build their own houses. Turns out, they’re rarely satisfied with the first one they live in. Generally, they aren’t satisfied with their second try, either.

If it takes three tries to design the house you want, keeping in mind that living in a house isn’t exactly terra incognita for most people, expecting a business manager to know in advance exactly how a piece of software should behave is several percentage points less than realistic.

And that’s starting with the false assumption that “What do you want the software to do?” is the right question to ask. It isn’t. A far better question is, “How do you want to run your part of the business differently and better?”

Even when IT asks the right question, the fundamental difference between the past and the future still intervenes. Presumably you know what this difference is: You can, in principle, get a pretty good handle on what’s already happened.

The future isn’t like that.

Comments