FunctionalStaffOrganization

team organization

tags:

In general PreferFunctionalStaffOrganization to to TechnicalStaffOrganization

Functional organization implies that you organize your teams along the line of business functionality. In a large organization this leads to teams organized either around large applications or into departments that look after a family of applications that support a business unit. As you go finer grained you see developers organized into supporting small applications or functional areas within a larger application.

The greatest strength of a functional organization is that it ties social structures to delivery of business value. In my view software projects succeed as much as they improve the effectiveness of the activity they support - yielding business value. By organizing your teams the same way, you have a team oriented around satisfying their business users - who after all are the ones paying the money.

Such an organization also allows developers to gain a better understanding of the business areas they support. The more domain knowledge developers have, the more it improves their communication with their customers and improves decision making over the software. Functional organization also allows developers and users to form better and longer lasting relationships.

Functional organization is particularly important at improving time to market. With a TechnicalStaffOrganization, you have to spend a lot of energy getting people who don't particularly care about the business needs to do things to help get a project moving. People in technical layers aren't invested in business value and aren't driven to get things done. In such an environment getting some business value out involves coordination akin to aligning planets, with similar timeliness.

Functional organization discourages over-engineering, since everyone is more closely attuned to business value than they are to technology. This is particularly important since nerds are prone to getting overly interested in functionality. Technical support layers tend to be too interested in a perfect general solution rather than a pragmatic answer to a business need.

In such teams you don't see individuals specializing deeply in technical aspects. This gives them a wider view of solutions instead of a narrow focus on technical camps.