- The Dimensions of an Organization
- Sample Organizational Structures
- Recurring Organizational Themes
- Thirteen Organizational Structure Mistakes
- Harris Kern's Enterprise Computing Institute
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Thirteen Organizational Structure Mistakes
Whatever the size of your software development organization, there are certain mistakes you need to avoid. Good organizational structure is a matter of management theory, science, and experience, not luck. Following are our "unlucky 13" mistakes:
Combining software development and operations into a single organization.
The job of operations is to keep applications up and running. The easiest way to do this is to never change anything. Combining development and operations into a single organization has the natural tendency to stifle innovation. Software development organizations should be separated from operations to allow new and modified applications to be developed as required to support the business needs of the company.
Organizing software technology specialists by project.
A modern day software development project requires a wide range of software specialists during different times in the software lifecycle. If you have a small organization with only one specialist and two projects, the specialist clearly needs to work on both projects, perhaps at different times. As your organization grows and develops more specialists, you still want to have specialists work across projects wherever and whenever they're most needed. But what happens if you assign technology specialists by project and each project ends up having a small number of specialists that must act as generalists, while doing the work of another specialist assigned to a different project? The result is that your organization as a whole cannot take advantage of all its specialists where they're most needed, and fails to take advantage of the synergies of being one integrated development organization.
Organizing software technology specialists by application domain (financial, manufacturing, and so on).
This results in the same problem as mistake 2 above. Given a fixed headcount, each application domain receives a smaller group of specialists who therefore are driven to become generalists. There is no room for software technology specialists who span across application domains, such as a GUI design specialist.
Organizing software developers by delivery platform (Windows, UNIX, mainframe, and so on).
Developers tend to develop a bias in favor of their assigned platform. As a result, there tends to be little or no innovation in new platforms (such as network computers) or cross-platform approaches (such as web-top computing or client/server systems).
Separating software development and software maintenance groups.
When you separate software development and software maintenance, you end up requiring the same types of software specialists for each group. This means you either have to double headcount in your organization for specialists or force one group to reduce specialization. In addition, it becomes harder to create incentives for software developers to do things right the first time, as they know another group will ultimately be responsible for fixing any mistakes. Such an organization also tends to develop two classes of software developers, leading to morale problems.
Representing projects in the formal organizational structure instead of defining project teams that cut across organizational boundaries.
This strategy leads to reorganization whenever a major project ends. As a result, software developers spend an inordinate amount of time looking for their next job or find unnecessary reasons to prolong their existing projects.
Organizing software developers into long-term and short-term development groups.
Again, this type of organization requires two of every software specialist and builds unnecessary competition between the two groups. In addition, this organization often encourages point solutions that may be quicker to implement but cost more in the long term, because of higher maintenance costs and difficulties in integrating with enterprise-wide applications.
Designing organizations that need "super-developers" to succeed.
In today's complex software development environments, no single developer can be a specialist in all fields. The organization should allow developers to become true specialists in a single field and reward them accordingly. The workload should also be managed to allow software developers to lead balanced lives. No one can work 18 hours a day forever and be expected to maintain his or her work quality and personal satisfaction.
Designing organizations that tolerate underachievers.
This is the corollary of mistake 8. A healthy organization employs everyone's complete range of talents to the fullest. Software developers who are allowed to underachieve will become bored with their work, which will only lead to poorer quality and further poor performance.
Designing organizations that reward empire building.
Organizational structures should eliminate all incentives for empire building. This means providing equal career paths for both senior-level software engineers and software development managers. Along the same lines, career paths should be provided both for software generalists and software specialists, as both are needed in a healthy organization.
Setting organizational goals that compete against each other for customer satisfaction.
Customer satisfaction should be the ultimate goal of all software development organizations. One organization should not have goals whose achievement negatively affects the customer satisfaction of another organization. For instance, if two development groups are working on applications for the same customer that must ultimately be integrated together, one organization should not be rewarded for meeting its timelines if this was only done at the expense of creating a more difficult integration task for the second group.
Organizing around individuals instead of personality types.
Every experienced software development manager recognizes the importance of matching a developer's job to his or her personality; however, even in the most stable of organizations, individuals come and go. You shouldn't design organizations around individual personalities. Instead, organize them around more general personality types. This allows the organization to recognize the value of individual diversity without having to reorganize every time someone comes and goes.
Mandating organizational changes from the top down.
All software development organizations eventually must change to adopt to new business models, technologies, or clients. However, mandating a structural change has little or no effect if it's not accompanied by cultural and process changes. The best way to assure successful change is to manage it via a participative process in which all developers are given a chance to affect the final outcome.