Designing organizational structures, inside-out? Outside-in? Mixed?

by Jurgen de Smet – Certified Creating Agile Organizations Trainer.

When one designs an organization’s structures, one can decide to do this either with an outside-in view from the end user perspective or one could choose to do with an inside-out view from the technology and architectural perspective.

Inside-Out Perspective

Many organizations out there choose to go with the inside-out perspective, being influenced by Taylorism, a management theory developed by Frederik Winslow Taylor in the late 19th century. Taylor believed that work could be analyzed and broken down into individual tasks and that each task could be studied to determine the most efficient way to perform it. He also believed that workers should be trained to perform their tasks in the most efficient way possible and that managers should closely supervise their work to ensure that they were following prescribed methods. Taylor believed that there is one best way to perform a task, and management determines that best way. Taylorism had a significant impact on the manufacturing industry, as it helped to increase productivity and reduce costs by optimizing work processes by providing a precise KPI and measuring performance. This worked for (simple) production systems but nowadays, the work we do in development is about discovery and the Taylorism approach does not work so well. Yet, a legacy we drag along and is reflected in our focus towards resource efficiency.

BASE Company (2016-2018) was no different and before going “Agile” they had a very traditional organizational structure based on internal technologies, applications and systems, having role-based teams. Very much maximizing resource efficiency, keeping people working as much as possible within their main skillset. It makes a lot of sense to them, having people repeatedly doing similar things over and over makes them more efficient, doesn’t it? Yet, they wanted to become “Agile”.

Outside-In Perspective

Let’s see what Mike Beedle says about Agile: Agility is the ability of an organization to adapt to new conditions and to change its direction while creating maximum value and customer experience.

As you can notice, the customer is a central piece of the puzzle and thus an outside perspective on organizational design might just be a more appropriate choice. Similar to the first organizational design guideline 1 within Creating/Designing Agile Organizations: “Organize in Product Groups” which includes (1) avoid designing the product group from the inside out from a technology perspective as well as (2) prefer designing the product group from the outside in from a customer-outcome perspective.

Yet, that doesn’t mean an organization immediately buys into the idea!

Even though well-described patterns and practices on designing an organization from the outside in, many out there have to learn this first-hand while experiencing the effects of an inside-out design approach. Within my engagement with BASE Company that was not any different. Let’s explore their learning journey together. 

Mixing different perspectives

At BASE Company we initiated a “deep and narrow over broad and shallow” adoption approach, within the boundaries as set forward by their former IT Director. A deep and narrow approach enables the organization to learn more quickly what could and could not work for them. 

At that particular moment, we identified the most favorable option was initiating the adoption process within their Data Warehousing division. Compared to other teams and departments, they had fewer dependencies, making it a suitable starting point; and they were serving highly important (internal) customers (Marketing, Financial Controlling…).. An inside-out approach, having a higher focus on internal systems and customers versus outside customers and their expected outcomes.

We shifted the Data Warehousing structures and operations from handling projects and doing resource management towards a team-based organization, the entire group designed themselves into 5 teams working on a single product backlog. Projects became just another item in the product backlog, the dedicated teams learned how to collaborate across different skill sets and across teams in order to deliver the highest value item first. Focussing more on flow efficiency, prioritizing the rapid delivery of value to their customers, rather than solely focusing on resource efficiency.

3 Months into this narrow adoption approach we sent out an inquiry to the main stakeholder group where the results were impressive. 92% of the respondents did experience a faster time to market, 100% of respondents did notice an increase in quality, 92% felt a change was handled more effectively and 92% said the teams were more productive. Leading to a NPS score of 83% for the new way of operating.

Mental Models

The above inquiry results became the turning point for the people in the organization, including C-level management. From this moment on C-level management got involved and wanted more of this “yesterday”. Not taking enough time to investigate and analyze their organization and rather making quick decisions based on past experiences. Because we focus on Data Warehousing, an internally focused design element, they did not experience abandoning the internal design perspective and thus came up with an internally focused design for their entire IT R&D organization.

• • 1 backlog for the entire organization, called Enterprise Backlog

• • Different multi-team Scrum units, called Value Areas

• • An integration unit & Project Management unit

Even though the multi-team Scrum units were called Value Areas they were highly internally focussed on technical components like CRM, SAP, OSS, as well as on skillsets like Front End for example. Definitely not connected to the Value Area Pattern as recommended by “Creating/Designing Agile Organizations”. I did try to warn about the negative side effects of this organizational design (a structure that avoids having truly value base backlog items and will end up with more system-oriented backlog items, a structure that requires lots of cross-area coordination to deliver end-to-end value as one still have to deal with dependencies, etc.), yet, we stayed with the structure based on their strong beliefs, mental models grown from past experience. The iceberg of systems thinking at play! Their past experiences and mental models were not at par to radically changing their organizational structures (units, departments …).

Going all in

The result was known as the BOLD 1.0 change and soon the people in the organization learned that it was not the optimal structure to generate maximum value and customer experience as operational dependencies stayed intact. This time C-level and their executives did take the time to analyze things more appropriately. Taking an outside in perspective doing so, a customer-first approach (creating/designing agile organizations, agile organizational design guideline 1, organize in product groups).

Next to analyzing their internal structures they also went out to have a look at how other TelCo operators were structured (designing agile organizations, coaching for change guideline 6, helping people cross the edge). They even found some standards in that domain. Firstly stumbling on TAM (Telecom Application Map) realizing that would again be too much of an inside-out view of things. The standard that did help was eTOM (enhanced Telecom Operations Map) which was more of an outside-in view on TelCo operators. Almost the entire organization got trained in the concepts inside eTom which helped all to take a more outside-in view and take the time to properly analyze a new setup.

The result was known as the BOLD 2.0 change where earlier multi-team Scrum units were reformed into proper customer focussed multi-team Scrum Value Areas. Each Value Area got a proper “reason for existence” within the organization, directly connected to its end users. Below is a subset of their new Value Areas.

As a result, most of the Integration and Project Management unit activities moved into the Value Areas, reducing overall organizational complexity even more. A single Value Area got full ownership delivering end-to-end customer value, as such there was no need for a separate group to coordinate the efforts from different groups; there was no need for a separate group to integrate different pieces of the puzzle into a single release; and I bet you can imagine some other benefits by now, don’t you? Additionally, the executives took up a more coaching role towards their organization resulting in significant additional improvements driven from the bottom-up.

At that moment BASE Company, owned by KPN, was acquired by Telenet. The moment my engagement stopped and I have no first-hand information on how things continued (only second-hand rumours).

Conclusion

Even though I have no data at hand to compare what happened with a “what if” situation where more time was spent analyzing. Having a BOLD 1.0 with real Value Areas versus internal focussed units. I do feel that taking the time to properly analyze would have been a more appropriate approach, avoiding some of the chaos, tensions and frustrations, probably saving us some time to get to where they ended up anyhow.

In that sense, we recommend that in order to deliver maximum value and customer experience you should take an outside-in perspective to engage in organizational design, and at least try to ignore past experiences that hamper this. Start with your users and the outcomes they want to achieve, if not, tension will arise which might lead you back to where you came from. Or… becomes the trigger to another bold change for BASE Company.

An experience very much in line with the recommendations and guidelines within Creating/Designing Agile Organizations.

* Webinar recording BASE Company adoption: https://youtu.be/y1l3-Fvko0s