Ghouls

A recruiter called me. He got word that my previous employer is now out of business, and called to beg me to sign up with him. I suspect most of my former co-workers are getting those same calls right now.

I suppose this is time for me to be a ghoul too, and do my own post-mortem on why this company folded. I won't name this employer, or name names, but here is how I see it:

1. Culture wars within the company. You had the Sun contingent. You had the SGI contingent. You had the Linux penguin contingent. The Sun contingent liked simple, not-very-complex programs written in "C" that were not theoretically "perfect" but were fast and efficient. The SGI contingent liked complex frameworks written in "C" that were wonderfully full-featured and "perfect" but where performance didn't really matter much to them. The Linux penguin contingent saw no reason to use "C" if you could use Perl or Python, no reason to use Perl or Python if you could use shell scripting, and valued simplicity and ease of modification above all else. The Sun people didn't talk to the SGI people. The SGI people didn't talk to the Linux people. The Linux people would talk to anybody but nobody wanted to talk with them because they weren't around during the 1980's when the Sun and SGI people were earning their chops. The end result was a software stack that was an incoherent mush of conflicting philosophies.
2. Poor engineering processes and management. This company had a crack team -- the best team I've ever worked with. But the above culture wars meant that the engineering staff was unfocused and fighting internal wars about how things should be done. They needed engineering management as brilliant as the engineers to crack heads together, get a design banged out, and set schedules and priorities and get the product out the door. Instead, the engineering staff went round and round in circles until finally a manager came in who was capable of cracking heads together and getting a product heaved over the portal. One of the consequences of the poor engineering processes was...
3. Unrealistic scheduling. Milestones were continually being shoved over the portal for the first two years, and the end result was to hurt the product design because people did quick hacks rather than doing things right. Which led to...
4. An inflexible software architecture that was hardware-dependent, meaning that...
5. It took too long to design and release the second-generation hardware product after the first generation product became obsolete, because the software architecture had too many hardware dependencies enshrined all over the place in it. Which was curious, because one of the company's other big problems was...
6. A software-oriented mindset. This company was founded by software geeks who wanted to create a new filesystem. Investors pushed them to put out a hardware-based product instead. But they never had the mentality of a hardware company. People involved in the hardware and manufacturing side of things were undervalued and left because the company viewed itself as a filesystem company that happened to manufacture hardware, rather than as a hardware company that had a unique filesystem. The result was hardware that was buggy and too expensive because outsourced design vendors did not have the supervision to push them to cost-simplify their designs. E.g., a particular circuit board that could have been easily done in a six-layer process for $10 apiece was instead done in a very expensive process that cost $250 apiece. But without a board-layout expert on staff, the software-oriented staff of the company had no way of evaluating this design and simplifying it (or directing its simplification) so that it could be manufactured in a cost-effective manner.
7. Which brings up the next problem: Lack of hardware and manufacturing expertise. They never hired the hardware design people needed to be a successful hardware company. They never hired the manufacturing experts needed to manufacture the product in an efficient and timely manner. This was part of their software-oriented mindset. Not only did they undervalue the contribution of those who managed to get the hardware designed, tested, manufactured, and out the door, but they didn't hire real expertise in the first place. The fact that I was their manufacturing expert who set up their manufacturing process should be a Clue(tm) there -- my previous experience had been years earlier with small "white box" vendors, not large complex systems. But they never hired the real experts needed to manufacture these systems more efficiently than the crude system that I cobbled up in my "spare time" to get product out the door.
8. Unwise outsourcing moves. They totally outsourced hardware design rather than hiring their own hardware design expertise, and the result was a hardware design that was buggy and not cost-effective. They outsourced their manufacturing to an expensive "prestigious" manufacturer so they could say "our systems are manufactured by prestigious outsourced manufacturer X" rather than doing it inhouse or using a less prestigious but cheaper assembly house, and the result was huge overhead costs compared to hiring a couple of Vietnamese assemblers to do it in-house (this was a low volume high end system, remember).
9. LATE TO MARKET. The combination of all the above meant that a system that would have blown everybody away if released in late 2003 was "ho hum!" when released in early 2006. Late to market was the core of their problem. They lost their window of opportunity, and it never came back because the same factors that led to them being late to market with their first-generation system also led to them being late to market with their (never-released) second-generation system.

So there's some lessons to be learned here, I suppose. If you are going to manufacture hardware, hire your own manufacturing and hardware expertise, don't think you can outsource it all, and value your manufacturing and hardware expertise, don't view it as secondary to your brilliant software solution. When you are hiring, hire brilliant managers as well as brilliant engineers else your brilliant engineers are going to run in circles and never get product out the door. And get product out the door early and often... if your staff never gets accustomed to shoving product over the transom in a regular manner early on, they never will be, and you'll always be late to market.

So it goes. That's just how it works here in the SillyCone Valley. By the standards of the Valley that former company was not all that bad -- they ran a lean operation that didn't waste investor money on a lavish HQ and other such silliness, unlike most SillyCone Valley startups they did get the first-generation product out the door even if it was late, and they did manage to manufacture product in a timely manner even if various decisions meant that the process was clunky and not cost-effective. So by the standards of the SillyCone Valley they did better than most. But "better than most" is not good enough in this Bush economy, and eventually the investors decided that "better than most" wasn't going to give them the returns they wanted. And so the investors pulled the plug and undoubtedly are going to auction off the technology to the highest bidder. So it goes in the SillyCone Valley... and soon enough, the investors who own the United States are going to pull the plug on the United States and do much the same for us. I wonder who the highest bidder will be... Zimbabwe, or Ethiopia? Be prepared to say hello to your new Ethiopian overlords!

-- Badtux the Snarky Penguin