Review of Learning, Part 1: Organisational Structure

Post date: Oct 16, 2014 10:9:0 AM

Reflecting on my career and experience to date, moments of learning and my continued reading and exploration of ideas has resulted in the following views. Here's an overview of what I believe are appropriate ways to approach working with teams of people involved with software delivery.

The System: Organisational Structure | By Function or By Product

As Mullins (2009) describes, within the formal structure of an Organisation, work is typically grouped around a major purpose or function, in essence departments of specialists within an organisation. In larger organisations, the many people and skills involved with software delivery are typically separated across departments and divisions. For example, Product Management, Business Analysis, Front-end and Backend Software Development, Testing, Operations and Infrastructure.

As observed by Parkinson (1942) in his Law ‘work expands to fill the time’ and the rising pyramid; a manager of these specialist departments will inevitably recruit more people and grow their area of the organisation, as the demand and utilisation of people within their department or area of specialisation increases.

This departmental separation of people involved with software delivery has resulted in the need for methods to coordinate across those departments, when delivering any work that requires their specialist skills. To achieve this collaboration organisations have made increasingly heavy use of Projects, in an attempt to deliver valuable outcomes across these departments of specialists.

According to the OGC (2009) Projects are defined as temporary organisations, which are created to deliver one or more business products in accordance with an agreed business case. This approach to creating temporary organisations incurs a large overhead of setup and coordination through delivery. Once the project is complete, there’s also a need to hand-over to the teams who will provide ongoing development and operation support for the delivered software platforms.

In my experience this approach to Organisational structure and a Project mentality are the root cause of organisations failing to realise sufficient value from their initiatives, within an appropriate period. As Deming (1986) observed: No amount of care or skill in workmanship can overcome fundamental faults in the system. The system we have in many large organisations determines the performance of the people within them, something that those people rarely have any control over, especially those involved in temporary project teams.

The implications for Organisations looking to realise value from features involving the delivery of software are not insignificant. Conway (1968) suggested that organisations build system (broadly speaking) which are copies of their communication structures. This can be directly observed in software systems, whereby teams of specialists have built software systems within the context boundaries of their organisational structure and specialisms. For example, a front-end software specialist who doesn’t have the skills, knowledge, or close collaboration with a backend software specialist, will often work around that limitation and implement inappropriate rules or logic within the front-end software. Resulting in many problems, but most typically with the dissemination and replication of business logic across multiple software systems, which ultimately results in blurred lines of control and reduces the ability for a business to enact change.

Matrix management has attempted to address this problem, but this approach disregards the importance of the psychological contracts that form between people. I’ve often heard terms like “gone native” to describe (in a negative way) people from a matrix capability area, who have become more embedded in the product or service area to which they’ve been assigned.

In addition to the complex human aspects, from a more fundamental financial perspective it becomes increasingly difficult to accurately measure the cost vs. benefit for any new or existing initiatives or products, given the shared cost across multiple specialist departments.

Mullins (2009) describes an alternative to the division of work by major purpose or function, as to organise work by product or service. The division by product or service is an integrated semi-autonomous unit of different specialists, which share collective responsibility. In essence a cross-functional team working together to achieve the common goal of that product or service.

A pragmatic but considered approach should be taken when constructing a cross-functional team. The individuals within these cross-functional product or service teams are responsible for what Woodward (1965) refers to as ‘task’ functions; activities that are related to the completion of their overall objectives.

It would perhaps not be appropriate for some specialised departments which provide more of what Woodward refers to as ‘element’ functions; activities that are supportive of the task function. I suggest that this is not something that can be predetermined, the inclusion of certain specialists within a cross-functional team is very dependant on the work involved. Careful assessment of what skills and people would be appropriate must be assessed, based on the challenge, tasks and ultimately the value required.

Maslow (1966) observed that people with specialist skills will look to apply them regardless of how appropriate they are to the task at hand. The importance understanding this point in software delivery teams cannot be underestimated. For specialist people who are more often than not working across departmental boundaries, and typically engaged together for the duration of a project, it’s my opinion that an alternative organisational structure would be more appropriate. For these specialist individuals, organising work by product or service would be a much more efficient organisational structure, and would result in better outcomes and solutions for the business and their customers.

Deming’s (1986) ninth of his 14 points for Management, states that the barriers between departments should be broken down, and for those people to work together as a team. This enables the team to foresee problems that may be encountered with a product or service, during its production and use.

Key points:

• Organise work by Product or Service not Function

• Think Products not Projects

• Carefully consider the skills needed to build cross-functioning teams

References

Mullins, L. (2009). Management and Organisational Behaviour, 8th edition, Pearson Educational.

Parkinson, C. N. (1942). Parkinson's law, and other studies in administration.

Deming, W. E. (1986). Out of the crisis. Cambridge, MA: Massachusetts Institute of Technology. Center for Advanced Engineering Study, 6.