However, with the release of Elemental it seems Stardock is beginning to transition from a small firm, that can be easily managed from the top-down by a single individual, to a much larger bureaucracy.
How so? The company is small and housed out of a single building, and it is privately run. Brad even showed us a standard chart for each development team, and the teams have only necessary pieces, and sometimes those pieces are in multiple places (Wearing many hats, as it were).
The company is small now, but it is expanding and getting larger. It wont be small forever I can assure you that.
The key question though, is how do decentralize management while still ensuring the company is known for quality and can still attract the love and adoration of its customers that it was able to as a small enterprise.
No. No no no. In a software company, decentralizing management is terrible. It's why we end up with games like Civ V - Pleasing too many people (i.e. shareholders, publishers, corporate management from all directions) because of a non centralized management. When you're in software, the fewer people you have to deal with to get to the top, the better.
Yes. Yes yes yes. Stardock has decentralized management look at their "about us" page:
Brad Wardell - President/CEO
Angela Marshall - VP of Operations
Kris Kwilas - VP of Technology
Jeff Bargmann - Chief Technology Architect
Phil Madis - Director of Business Development
Kirk Windisch - Director of Software Development
It would be absolutely insane to think that Brad Wardell could manage everything. No small or mid-size firm could exist without delegating management responsibilities.
As it is right now I love your work, your company, the products and services you and your employees are able to produce and I eagerly await the next thing you guys come up with. In the mean time I'll remain hopeful that as your firm becomes larger and expands that you don't go the way of <insert 99% of all American firms here>.
If you like the company, why do you think it's transitioning in a negative way?
My concern is with the botched release of Elemental. I have to ask is this a sign of things to come? How is the company being managed? Does all responsibility fall on Brad Wardell? Is the success of the company and the quality of its products dependent on a single man? If the answer is yes, its not a good design principle for a company that is getting larger and expanding every day. If at the end of the day quality of every product must be managed by a single individual then its a recipe for more and more products being released of progressively lower quality. I would be very sad to see Stardock, a company that I have come to see as having a heart and soul all its own, head down that direction.
On the other hand, if the company is looked at as a system, and that system is engineered so it can be self correcting when defects or statistically significant variations in quality occur then I wouldn't be too concerned. The system is no longer solely dependent on a single individual, it is dependent on its internal design. TQM is one such management framework that paves the way for a constantly self correcting system that leads to progressively higher levels of Total Quality. It simply not good enough for a CEO to take responsibility for a bad product and make sure it gets fixed. I'm not saying its a bad thing, it is definitely good when a CEO takes this kind of initiative. However, my point is that the ultimate responsibility for quality shouldn't be on the CEO directly, but on the system itself. The CEO should lead management, but not have to micromanage quality. Lets say Elemental gets fixed up nice and neat. Then going forward is there an inquiry to how and why it was released with such low quality? Does anything get built into the system itself to ensure it doesn't happen again? If the system isn't designed to be self correcting then its just a matter of time before the exact same mistake is made again. If that is the case then I'm concerned for Stardock going forward. Brad Wardell is an incredible CEO, as far as I can tell, but he isn't superman. Some tools that can help address these challenges are quality circles or specifically Deming's PDSA cycle.
On the other hand if Brad Wardell is familiar with management designs that create a constantly self improving system with some degree of independence from top level management then I'm not too concerned. As it is right now, I don't know. Stardock is privately held and as such they don't release 10-ks so I can understand how the business is run. If Brad Wardell hasn't implemented management principles such as TQM or those that have the same net effect as TQM I would propose that he look into it while the firm is still small, because the longer its put off the more it will cost down the road. If such management design is never implemented then eventually (assuming that Stardock continues to grow and expand) it could very easily become just another large shoddy software firm, and I would be quite sad if that ever happened.
Edit: Since everyone who has responded to this thread so far only thinks that TQM can be applied to manufacturing processes then I would suggest that you at the very least go to your local library and skim, even just briefly the first two chapters of Out of the Crisis. You'll see very quickly that it can be easily adapted to just any industry. Yes, it has already been adapted to the software industry. Again, it provides a framework for constantly improving processes on a scientific basis in a firm. It doesn't matter if your manufacturing cell phones, running a hotel chain, or designing software. At its heart TQM is a platform for reducing waste, creating more efficient and constantly improving processes, and constant improvement for quality in all aspects of the firm, not just the end product. As an example Toyota adopted TQM and over time evolved their own business model called "The Toyota Way." Stardock, likewise, would evolve their own business model from using TQM as a foundation. It would not look anything like Toyota's model, though. Stardock would end up with a "Stardock Way," so to speak, which would be specific to the software industry, not manufacturing.
Since no one has bothered to read it I'll post it again, but here is a link for an article regarding TQM in the software development process.
Here is a blogpost on TQM in software development.
Here's a chapter from a book titles, "Managing a Software Development Organization with a TQM Approach for Balance ina Period of Rapid Growth"
Here is the abstract: Software organizations rely on quality models designed for their specific purposes, the Capability Maturity Model Integration (CMMI) being the most prominent model to follow. However, in striving for both product and process quality in their activities, small and medium sized enterprises with a limited legacy of organizational culture and tradition in quality work, may profit from quality frameworks following the Total Quality Management (TQM) principles. The ISO quality standards (the 9000 series) provide such principles. A further framework suggested by the European Forum for Quality Management (EFQM) also gives a set of principles to follow. In a case study, we investigate how the principles of the EFQM model can be translated into practical use in a relatively young but rapidly growing software company. We suggest a “double bladed” quality tool to be used by small and medium sized software organizations: supporting the managerial work with TQM principles derived from the EFQM, together with process improvement efforts following the CMMI model.
Also I would just like to say that I am amazed, either intentionally, or by happy accident that many of the principles of TQM are already followed by Stardock, which is why I thought it might provide some appeal.
However, I am not certain if Stardock adheres to some principles which I believe to be very important for constantly improving quality. Maybe Stardock already follows them, maybe they don't I dont know. The following is extracted from the first article above:
Quality must be built into the product. Quality cannot be an afterthought. It must be constantly measured and quantified. The question: “Is this good quality?” must be a centerpiece in any development project. It must be a concern from beginning to end. Quality is not determined by picking the best of the bunch after production and recycling the bad ones. “Bad ones” should never exist in a TQM environment. Defects should be discovered before any production occurs. This is accomplished by building quality into the product. It is easiest to understand this concept by thinking about quality as a part of a product. The product cannot work without the quality component installed. Therefore, during every stage of the development process, the developer must ask himself: “Have I installed the quality component in this product?
In this regards just think of "product" as software, algorithm, code, function, object, library, etc. Think of a defect as a bug.
TQM accomplishment involves continual training. Continuous improvement includes the improvement of one's ability in performing one's job. An employee must be trained in TQM principles and in the tools and techniques for implementing TQM. Such training credential should be treated as an accomplishment for performance evaluation
Here, what I think is essential is that each employee must be trained in the system for continual process improvement that the software firm has developed. If an employee notices that a process can be improved and improve overall Total Quality then the change can be integrated into the process and the process is redesigned. Basically, every employee plays a role in the design, development, and evolution of business processes through constant feedback between employees and management. In this way management does not decide the processes to be followed, rather it is defined through constant cyclical feedback within the system itself.
Long-term emphasis on measurable processes and productivity improvement. TQM cannot be implemented overnight. It is a long-term process that takes years to implement. It is a complete cultural change in the organization to focus on continuous improvement. The problem with achieving continuous improvement is that it requires measures to be compared against. Therefore, a key element of the TQM culture is qualified metrics–measurements taken continuously in order to chart progress
This relates to the last point, but what is important to note here is that continuous improvement must be objective, it must be scientific. You cannot simply say X seems like a good idea so lets implement it in our design process. Instead you must say X may address Y, lets test it and if it leads to a more effective process/higher quality then we will implement it on a larger scale.
Understand the current process before improvement begins. We must understand how things work in the organization to be able to improve it. Understanding how it works involves being able to measure the process in order to compare “improvements” against it
Again the emphasis is on objective and scientific evaluations of any given process.
Cross-functional orientation and teamwork. The essence of cross-functional teams is to integrate many different parts of the organization into the development process. For instance, programmers must involve users from finance, accounting, marketing, and other departments in the development of a software product. This philosophy is developed with the thought that developing a product is not just the designer's concern. Everyone who is involved with the development, distribution, and maintenance of a product should have a say in the development of the product
The emphasis here is that every single department in the software firm must communicate and work together.
Effective use of statistical methods and quality control tools. Statistical quality control and process control techniques should be used to identify special causes of variation that are points outside the control limits. Actions should be taken to remove these special causes. Moreover, any abrupt shifts or distinct trends within limits are also signals for investigation. Quality control tools such as the Quality Seven (Q7) tools and the Management Seven (M7) tools [Brassard, 1989; Imai, 1986; Ishikawa, 1976] may be used to plan for actions, collect valuable data, and chart for progress. Table 1 lists the names of these tools and their descriptions while Figures 1 and 2 display their formats. The Q7 tools are used to analyze historical data for solving a particular problem. Most problems occurring in production-related areas fall into this category. One the other hand, not all data needed for decision making are readily available and many problems call for collaborative decision among different functional areas. Under these situations, the M7 tools (also called the New Seven tools [Imai, 1986] are useful in areas such as product quality improvement, cost reduction, new-product development, and policy deployment, etc.
Here just replace "production process" with "design and development process" The emphasis is once again on using empirical data and the scientific method to improve processes. When there is no clear data set to analyze statistically Quality Circles / Deming's PDSA Cycle can be important tools to process and organizational improvement.
Constant process, product, and service improvement. A culture of constant improvement must be developed for TQM to succeed. All employees should be empowered with the ability to influence an organizational process that helps to improve quality. Once given this authority, employees must show their desire and commitment to constantly improve the company. They must be always looking for ways to improve not only their part of the organization, but also the organization as a whole. Management must foster this culture through proper reward and recognition.
The key emphasis here is worker empowerment to help foster an environment where all the above points can effectively take root. From what I can tell Stardock, already seems to employ such empowerment strategies with those employees who are part of the development process. However this principle shouldn't exclude other departments including but not limited to accounting and marketing, for example. So here were not just looking at the quality of the end-product, but Total Quality in the entire operational structure of the entire firm.
Eliminate communication barriers. Under TQM culture,there should be no communication barriers between workers and management, and between functional areas.The management must make themselves available to and easily accessible by theworkers. Employee suggestion program could be implemented in order to eliminate communication barriers.
An important principle, which Stardock may already succeed at, but this is a key piece that makes the feedback cycle for continuous and constant improvement work.
Stardock Forums
Elemental Forums
A bit like Stardock itself. But that doesn't mean that Elemental, Impulse (and other products) can't be great going forward. 
But I'm sure they don't because that would mean voluntary turnover, so I'm sure it never existed in the first place)
GalCiv2 Forums