Case Studies required of Software Business Failures?
July 16, 2012 8:51 AM Subscribe
I would be interested in hearing case studies for software business failures that have occurred due to one or both of the following factors:
- Wholesale replacement of entire engineering staff (e.g. firing all staff in original location and replacing with staff in a new location).
- Winding down product development on existing products with the expectation that it will be replaced by a new platform in the future (I'm thinking along the lines of Ashton Tate here and their DBase product).
I would also be interested in hearing any examples of where either of these strategies has been put into effect, and it been a success, rather than a failure.
Background:
I work for a successful software and services company that is the market leader in a particular field, and has a pretty firm stranglehold on that market. The company has just fired virtually all its engineering staff world-wide working in that particular market, and plans to create a new cloud based version of the (rather specialist) software with staff it is planning to hire in Eastern Europe. I should note that this software portfolio is also integral to the services side of the business; without one the other can't exist (in its current form at least). Internally, it seems like a no brainer that this is a staggeringly bad strategy (though the board clearly seem convinced - perhaps down to the sophistry of the business unit's CEO). I would like to read about where this approach has been taken before in other businesses, partly out of curiosity, but also in case there are concrete parallels or lessons I can ensure are feed up the chain to the board.
Note - this restructuring hasn't been announced to our customers or shareholders (and won't be!), which is why I'm keeping this anonymous.
Background:
I work for a successful software and services company that is the market leader in a particular field, and has a pretty firm stranglehold on that market. The company has just fired virtually all its engineering staff world-wide working in that particular market, and plans to create a new cloud based version of the (rather specialist) software with staff it is planning to hire in Eastern Europe. I should note that this software portfolio is also integral to the services side of the business; without one the other can't exist (in its current form at least). Internally, it seems like a no brainer that this is a staggeringly bad strategy (though the board clearly seem convinced - perhaps down to the sophistry of the business unit's CEO). I would like to read about where this approach has been taken before in other businesses, partly out of curiosity, but also in case there are concrete parallels or lessons I can ensure are feed up the chain to the board.
Note - this restructuring hasn't been announced to our customers or shareholders (and won't be!), which is why I'm keeping this anonymous.
Another great one is Great Business Disasters by Isadore Barmash. It is about all kinds of businesses through about 1970, including the Penn Central railroad and the origin of Amtrak. Not much about software, but it does cover the RCA mainframe computer debacle of the early 1960s, which has some similarities, as all the articles do. This is a collection of the author's pieces from the 1960s in the Wall Street Journal and - Women's Wear Daily.
...are destined to repeat it.
posted by caclwmr4 at 9:30 AM on July 16, 2012
...are destined to repeat it.
posted by caclwmr4 at 9:30 AM on July 16, 2012
I don't have any stunning macro examples to point to in the public record offhand, but I can tell you from my experience seeing this exact kind of process happen in smaller scale (subproducts, features, helper apps, etc) the outsourcing never saves money in the end, and always causes delays in delivery of the new product from the new team, especially in the case where the old team isn't around to help the new team get up to speed.
So to sum up your company's position on this, you're market leaders with your current platform that you're replacing with something new and different, and also getting rid of all the engineering talent who built that existing platform. You're hiring a (cheaper) Eastern European team to build a new platform, presumably with little or no experience in your market and with possible/probable time zone and language barriers during this development cycle, and you're not planning on telling your customers OR shareholders about this sea change.
Good luck. Word *will* get out and your shareholders will be pissed beyond belief. And they should be, this is practically a how-to for creating a train wreck. As I think about it, there are a few parallels to what your company is doing with its product direction and RIM's current troubles. They too were the 800 lb gorilla in their space, and they've been doing their damndest to lose as much market share to competitors as they can though their fault is more a lack of watching competitors and arrogant confidence in their own platform.
posted by barc0001 at 1:27 PM on July 16, 2012
So to sum up your company's position on this, you're market leaders with your current platform that you're replacing with something new and different, and also getting rid of all the engineering talent who built that existing platform. You're hiring a (cheaper) Eastern European team to build a new platform, presumably with little or no experience in your market and with possible/probable time zone and language barriers during this development cycle, and you're not planning on telling your customers OR shareholders about this sea change.
Good luck. Word *will* get out and your shareholders will be pissed beyond belief. And they should be, this is practically a how-to for creating a train wreck. As I think about it, there are a few parallels to what your company is doing with its product direction and RIM's current troubles. They too were the 800 lb gorilla in their space, and they've been doing their damndest to lose as much market share to competitors as they can though their fault is more a lack of watching competitors and arrogant confidence in their own platform.
posted by barc0001 at 1:27 PM on July 16, 2012
A different thing to include in your list: In addition to "firing the whole staff", include "The entire staff quit or was hired away". This has happened several times in the industry.
One prominent example was when Microsoft began the "NT" project. They raided DEC and hired away the entire kernel development team who had been working on VMS.
VMS didn't die after that; DEC continued developing it right up until DEC went out of business.
I can't remember the specific case, but I know that at least one game company had its entire game development team quit en masse in order to form their own company.
posted by Chocolate Pickle at 4:19 PM on July 16, 2012
One prominent example was when Microsoft began the "NT" project. They raided DEC and hired away the entire kernel development team who had been working on VMS.
VMS didn't die after that; DEC continued developing it right up until DEC went out of business.
I can't remember the specific case, but I know that at least one game company had its entire game development team quit en masse in order to form their own company.
posted by Chocolate Pickle at 4:19 PM on July 16, 2012
By the way, if you yourself are a stockholder, and if you decide that this is going to send the company down the tubes and you sell your stock, it might be considered "insider trading". You should probably consult a lawyer before doing anything like that.
posted by Chocolate Pickle at 4:27 PM on July 16, 2012
posted by Chocolate Pickle at 4:27 PM on July 16, 2012
I think these must be very common scenarios, as I've seen both the "replace entire staff" and the "sunset legacy product before new uber product is ready" a couple of times each in my consulting days. I'm staying away from any specifics here because I'm still in the industry and my market isn't that large.
It is hard to draw conclusions from just a handful of data points, but there were two themes that seemed to be present in all of these scenarios I witnessed. First, some kind of large scale leadership turnover resulting in a new direction for the company (e.g. merger resulting in replacement of most/all of the C-level positions). Second, there seemed to be an ulterior motive that wasn't apparent up front, like positioning the company to be acquired or IPO or something. For example, firing your U.S. based engineering team and moving development offshore may be a bad long term plan, but if your goal is to plump up the balance sheet and improve the cash flow in the short term to faciliate some kind of exit for the company, that may be a gamble you are willing to take. Success can be defined in different ways and a happy ending for shareholders or investors may be disastrous for the product and/or engineering team.
You write, "Internally, it seems like a no brainer that this is a staggeringly bad strategy." While it is a common trope that C-level executives (and the boards they report to) are a bunch of idiots, it is not one I subscribe to. Assuming that you have competent executives and a board paying attention, you might ask yourself what other explanations would account for this strategy. One thing they have just accomplished by firing everyone is improving the expense side of the revenue statement. For however long they can coast on momentum from the current product, the P&L is going to look great. I don't think executive level stupidity passes the Occam's Razor test here, at least not without more information about how the company is structured and how the execs and board are compensated.
posted by kovacs at 8:47 PM on July 16, 2012 [1 favorite]
It is hard to draw conclusions from just a handful of data points, but there were two themes that seemed to be present in all of these scenarios I witnessed. First, some kind of large scale leadership turnover resulting in a new direction for the company (e.g. merger resulting in replacement of most/all of the C-level positions). Second, there seemed to be an ulterior motive that wasn't apparent up front, like positioning the company to be acquired or IPO or something. For example, firing your U.S. based engineering team and moving development offshore may be a bad long term plan, but if your goal is to plump up the balance sheet and improve the cash flow in the short term to faciliate some kind of exit for the company, that may be a gamble you are willing to take. Success can be defined in different ways and a happy ending for shareholders or investors may be disastrous for the product and/or engineering team.
You write, "Internally, it seems like a no brainer that this is a staggeringly bad strategy." While it is a common trope that C-level executives (and the boards they report to) are a bunch of idiots, it is not one I subscribe to. Assuming that you have competent executives and a board paying attention, you might ask yourself what other explanations would account for this strategy. One thing they have just accomplished by firing everyone is improving the expense side of the revenue statement. For however long they can coast on momentum from the current product, the P&L is going to look great. I don't think executive level stupidity passes the Occam's Razor test here, at least not without more information about how the company is structured and how the execs and board are compensated.
posted by kovacs at 8:47 PM on July 16, 2012 [1 favorite]
quoting
Joel on Software
Things You Should Never Do, Part I
by Joel Spolsky
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.
You are putting yourself in an extremely dangerous position where you will be shipping an old version of the code for several years, completely unable to make any strategic changes or react to new features that the market demands, because you don't have shippable code. You might as well just close for business for the duration.
You are wasting an outlandish amount of money writing code that already exists.
posted by at at 4:14 PM on July 17, 2012
Joel on Software
Things You Should Never Do, Part I
by Joel Spolsky
When you throw away code and start from scratch, you are throwing away all that knowledge. All those collected bug fixes. Years of programming work.
You are throwing away your market leadership. You are giving a gift of two or three years to your competitors, and believe me, that is a long time in software years.
You are putting yourself in an extremely dangerous position where you will be shipping an old version of the code for several years, completely unable to make any strategic changes or react to new features that the market demands, because you don't have shippable code. You might as well just close for business for the duration.
You are wasting an outlandish amount of money writing code that already exists.
posted by at at 4:14 PM on July 17, 2012
This thread is closed to new comments.
Those who don't know history...
posted by caclwmr4 at 9:21 AM on July 16, 2012 [3 favorites]