About Engineering Structures

Changing existing engineering structures is expensive and a risky endavour for any organization, while bootstrapping new organizations or preparing young ones for rapid growth are activities that can make or break any company.

Therefore, it is important to have an explicit and methodical approach to organizational design.

Through my professional experience in structuring engineering organizations, I have learnt that there are no infallible recipes or one-size-fits-all formulas for building successful engineering teams. However, I’ve landed on a conceptual model that has proven to be a valuable method to support the process of structuring engineering teams. This model emphasizes three key dimensions that serve as building blocks for effective team formation: architecture, people and methodology.

But, there is some work before digging into that.

Starting Point: Clear Understanding of the Desired Outcomes

When thinking about ideal engineering structures for a given organization, one must first ensure it understands correctly what the organizational desired outcomes and goals are. I know this sounds cliché, but for most organizations this is no small task. It is extremely frequent to encounter team members of any seniority who are confused about the intended outcomes and goals. Usually, intuitively this is clear, but it is not explicit and when someone attempts to verbalize it, confusion unfolds. The ability to clearly articulate it and to hear about it in different contexts is usually a good indicator on how well understood it is, so keep attent to that.

Proceeding with team structuring or high level technical activities without a clear understanding of the desired organizational outcomes and goals presents a high risk of overall poor engineering performance and organizational entropy with long lasting consequences.

Once it is known what needs to be done, it is time to dig into how to do it.

Engineering Structure

The Conway’s law states that systems will reflect the communication patterns and organizational structure of the team(s) building it. I have seen this happen too many times and at this stage I do believe it is a inevitability. Architectural decisions end up being made to accommodate existing organizational structures and technical decisions are made within incomplete contexts. When this happens, we have a situation which ends up leading to poorly performing organizations with difficulty to adapt to everchanging needs.

At some point, I concluded that it would make sense to adopt the inverse of Conway’s law for organizational design, which implies structuring teams according to the desired system. This means we need to start by defining the system architecture, which is to be designed to best address the desired organizational outcome and then on the back of it, to structure the organization that will support it. This realization was transformative for me.

This results in defining the system (architecture) which targets to deliver our desired outcomes in the best way possible, so that we can then define the organization (people) and then its communication patterns (methodologies) to best enable it for success.

I found this to be the healthiest approach to structuring engineering teams and to often lead to good collective and individual results. It obviously depends on defining the architecture correctly, selecting the right people, and adopting the appropriate methodologies - each with minimal failure due to the compounding effect.

As we don’t live in an idealistic world, while it is important to be faithful to this method, it will be necessary to accept compromises, as long as it doesn’t threatens to break its fundamental principles.

The approach to the definition of the architecture and structure should be done in a widely involving manner. Being transparent and explicit, while showing that there is a methodology behind the activity, will make everyone less uncomfortable about the process.

The way to execute the process and how to roll it out, will be completely circumstancial and has to be judged at the time and within the context.

There are Fractals Everywhere

Often, smaller organizations have simple structures and arguably they are the most efficient and effective organizations. However, in successful businesses there will come a time they will need to grow and as they grow, the complexity also grows and new challanges arise. Good inter-team coordination is not a small feat and when more explicit methodologies start to be needed, it is when greater management skill comes in most handy.

In any case, with growth it will be necessary to derive meaningful goals and organizations from the main ones. The architecture, people and methodologies triangle must adapt and accomodate accordingly those needs. In essence, the same principle has to be applicable at all levels and even for structures of sub-orgnaizations if justified.

It is natural to find in any organization goals within larger goals, architectures within architectures or structures within structures. One can even say that the meta organization must be architected to accomodate this structure adaptablity and flexibility as it naturally becomes one of the desired outcomes, in case it believes it is the right model to support its expansion.

Also, if the desired outcomes and goals change, the triangle has to adapt. Otherwise, it is going to be like using the wrong tool for a given job. Therefore, this organizational architecture requires the right type of people that feel comfortable in this type of ever changing environments.

It was also interesting for me to experience how organizations ended up, within their scope, adopting more creative and effective methodologies when compared with the existing ones, which ended up inspiring other organizations to become better. If done correctly, this model ends up delivering impressive results and an environment where people feel they have a direct impact on contributing to the organizational goals and with exciting prospects for their internal career development.