Optimal organizational structure for IT?

Question

There are many approaches to how to structure a company's IT shop to better fit the needs of the core business. In my scenario, developing web and mobile access is central to the the needs of the organization of which I am thinking. It is structured such that development is done by one group of worker bees, another for maintenance, another still for testing, etc. etc.

It seems this structure tends to lend itself to adversarial relationships because each area has its own measure of what success is:

Development --> Time To Market
Maintenance --> Stability of the environment
Testing --> Making sure they don't get spanked if something goes wrong.

There are many other organizational groups (for lack of a better term) for analysts, project managers, designers, etc. In a perfect world, these groups would create checks and balances against one another, but in the end priority invariably gets placed on TTM, sometimes to the detriment of the other players. This creates a lot of tension whenever releases come because an attitude of 'throwing code over the wall' prevails as the MO.

What other organizational structures have you observed in industry that better lend themselves to a greater sense of cohesiveness amongst the players?

Answer 1

One of my employers used a very different type of organizational structure that appeared to work very well and which I've not seen used anywhere else.

This was centered around the concept of each project being done by a relatively small and multi-disciplinary team that were brought together only for the lifetime of the project. A typical team could have multiple general software developers, a mathematician, engineers, testing technicians, server engineers, etc - all lead by a single project manager.

A person would typically be involved in multiple projects at any one time and so part of multiple teams. The project managers would liaise with each other to ensure that people were not being involved in too many projects and to ensure people knew their particular priorities. Each person would then be responsible for scheduling their own time to ensure they met their project commitments.

Each member of staff had their own private office (for the most part) so there was no need to physically move every time you join a new team. The building itself had a lot of meeting rooms/common areas to ensure that teams could get together very easily.

Being part of multiple diverse teams really did eliminate the organizational barriers - people would spend their average week working alongside a representative sample of the entire organisation and this resulted in the least amount of 'us versus them' adversarial thinking that I've experienced.

It also was a good way to ensure expertise was utilized correctly - staff could be dropped into a project in order to provide a particular skill or share experience very easily and without any need to change a persons management or reporting structure.

The whole system seemed to be built on the organization's very specific business model, high levels of staff motivation and very experienced and able project managers so I'm not sure how transferable any of this, but I thought it was worth sharing anyway.

Answer 2

Conway's Law states:

"..organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations"

The corollary of this is that the best organizational structure is the same as the best software architecture.

Not knowing the specifics of your business, I am basing the following on some sweeping generalizations:

Experience indicates that software development is both expensive and risky; and that this risk and expense can only (even with strenuous effort) be reduced to a very limited extent.

Since cost & the level of risk is (approximately) fixed, you need to increase returns to achieve an acceptable reward:risk ratio.

The first obvious consequence of this is that organisations should focus on projects with a big pay-off. This is not always achievable, as the opportunities might not exist in the marketplace. The second obvious consequence of this is that development costs should be amortized as much as possible. For example, by spreading development costs over multiple product lines & projects. (I.e. code reuse).

So, back to Conway's law: What organizational structure maximises code reuse? The obvious answer would be to align organizational units around libraries & APIs, with each developer responsible for one or more libraries AND one or more products. How libraries get re-used is then no longer a purely technical decision, but an important business decision also. It should be a management function to ensure that development costs are amortized effectively to maximise return per unit development effort.

Each developer then has responsibility for the development, testing & in-service performance of the features supplied/supported by his library.

Answer 3

I cannot see maintenance teams separate from initial development teams working. Generally speaking at least some of the developers involved in the core design and development should stay on maintenance for six months to a year(kind of thumb sucked that period out of own experience).

Maintenance developers have to struggle with the was-this-by-design problem, where they are unable to see whether a specific problematic area was made that way for good reason. It's easier for the original developer(s) to fix fundamental design flaws.

If a new maintenance developer is intended, both the original developer(s) and the maintenance developer should share some time maintaining the system. The core developer checks that the maintenance developer does not code around his design, and the maintenance developer gets a chance to ask questions about the fundamental designs and reasoning behind the code. Both parties learn and share responsibility.

Developers who have spent time maintaining rushed code will be more focused on code quality.

I Don't have all that much experience with testing but have found that it works better if testers draw up test plans together with developers. The test plans are executed at the testing phase and if all the boxes are checked the go ahead is given.

Answer 4

We used to have teams organized by client (or project) with a few specialists who supported mulitple clients. Then we went to the org structure of application developers and maintenance developers and database developers and the clients had to pool from a pool of people. This failed miserably. We are now back to the orginal structure and everyone is much happier.

One thing that happened when whe had a maintenance set of developers and application developers was that it became impossible to move from one category to another. Maintenance were looked on as having less skill and thus not qualified to change to be application developers.

Application developers in the meantime had no idea of the problems they created when they did a poor design because they never saw the support tickets. So they continued to make the same mistakes repeatedly. This of course annoyed the "less skilled" maintenance developers who had to fix the application developers mistakes while the application developers got all the recognition including pay raises and promotions.

Project managers were in a continual and time-consuming battle to get resources to do their work which created a lot of organizational hate and discontent. No one could prioritize work effectively because they didn't know from day to day who they would have available to do the work. This also took away from the time they had to actually manage their projects and some bad delays and overrruns occured because they didn't have the time to see what was happening because of spending too many hours a day fighting to get people assigned to their high priorities. Smaller clients were annoyed because they always lost the resource battle and thier high priorities weren't getting met. So they could have critical show-stopper bugs that weren't getting fixed.

Answer 5

ITIL and COBIT would be my suggestions for answers if you want to go way down the rabbit hole of how to organize IT in a company at a high level. I've seen some ITIL that looks like a good idea but I wonder how well can it be implemented and the organization mature in using the framework.

Answer 6

The best organizational schemes I have ever seen can basically be described as "amoebas." Just a bunch of guys (and gals) with common goals working to get there and organically swallowing everything in their path. You might have someone in a lead role on a specific piece, but when everyone owns everything some beautiful things can happen.

Unfortunately this sort of structure makes PHBs heads explode and is rarely seen in the wild.