Designing for Delivery: The Organisational Transformation of SIKT

By Arne Henrik Storm – Candidate Creating Agile Organizations Trainer.

Executive Summary 

The Challenge and Response: Studieadministrasjon (Student Administration), a 70-person product group within SIKT—Norway’s digital infrastructure provider for education and research—manages FS, the comprehensive student information system used by virtually all Norwegian higher education institutions. 

Facing some management and organizational challenges, including misaligned teams, unclear authority structures, slow delivery, and low employee motivation, the group embarked on the STA 2.0 transformation. Following the Creating Agile Organizations (CAO) approach, this 12-month transformation (Q2 2023 – Q1 2024) involved comprehensive analysis, strategic realignment, and structural redesign. 

Key Changes:  

• Eliminated dual reporting matrix that split authority between line managers and product managers 

• Restructured teams around three process-centric product areas aligned with operational strategy 

• Revised authority and responsibility for managers with combined authority and responsibility for each product area 

Strategic Focus: Aligned organization with operations-centric strategy emphasizing quality, automation, and cost reduction rather than innovation or user group customization. 

Results: 

• Significantly improved role clarity and decision-making speed 

• Better delivery performance and reduced coordination overhead 

• Enhanced focus on user outcomes rather than internal components 

• Stronger team autonomy and clearer priorities 

• Improved communication and cohesion across the product group 

Key Learning: The removal of matrix management and establishment of product areas with dedicated senior leadership proved most successful, demonstrating the critical importance of aligning authority with responsibility in organizational design. 

In this case study I will go into detail on the design process and choices that were made.

Introduction

The Company and product group 

This case study documents the organizational transformation of Studieadministrasjon (Student Administration), a product group within SIKT – Norway’s digital infrastructure provider for education and research.  

SIKT serves as the backbone of Norway’s knowledge sector, delivering critical IT services to universities, colleges, and research institutions across the country. Within SIKT, the Education and Administration division provides digital solutions that power teaching, learning, and institutional management. 

At the heart of this division, Studieadministrasjon manages FS – the comprehensive student information system used by virtually all Norwegian higher education institutions. This system handles everything from admissions to diplomas, serving thousands of administrative staff and hundreds of thousands of students daily. The product group counted about 70 people at the time of the transformation. 

The STA 2.0 Transformation Journey 

Facing increasing demands for agility and efficiency in a rapidly digitalizing education sector, Studieadministrasjon embarked on the STA 2.0 transformation – a journey from traditional hierarchical structures to a more agile and powerful organization. This case study explores their biggest reasons for change, the resulting organization and the effects this transformation achieved. The transformation took about 12 months from start to finish with the implementation of new teams and leadership structure.  

• Phase 1: Discovery and Analysis (Q2-Q3 2023) 

• “Pulse survey” and semi-structured interviews across all teams combined with organizational analysis and synthesis reveal six improvement areas.  

• Phase 2: Design and Planning (Q3-Q4 2023) 

• Redesign of sections, teams and reporting lines. Planning the implementation. 

• Phase 3: Implementation (Q4 2023 – Q1 2024) 

• Transition to process-oriented teams with sections with the necessary authority to deliver on their responsibility. 

Phase 1: Discovery and Analysis 

Misalignment, Uncertainty and Low Ownership. 

I was hired as an agile coach and management consultant. There were some issues that I was made aware of by management. 

• Teams were not working on high priority items 

• Teams were not delivering according to plans 

• Teams were disgruntled and unmotivated 

• Delivery speed felt slow by management. 

• Leaders unclear on their role and authority 

• Always reporting “yellow” status on projects and milestones.  

• Management and teams felt far apart. Both parties exhibited a “We and them” culture.  

For management, there have been attempts to fix some of these issues with new processes, but with little effect. A more systematic approach to finding root causes was needed. Hence, we turned to the CAO approach. 

Interviews, analysis and synthesis of problems  

When we started working on the issues facing the product group, no one fully understood why these issues kept resurfacing. To get an evidence-based overview, we began interviewing all leadership roles, including product owners, line managers, tech leads, teamleads, architects and product area manager.  While the CAO recommends starting with strategy, we began instead with a mapping of the current situation. We had an open mind and did not assume alignment or lack of strategy was the issue.   

The interviews, however, revealed that there were no immediate quick fixes. When we combined these insights with the work of Nicolay Worren (Organization-Design-Nicolay-Worren)  and Cesario Ramos’s book Creating Agile Organizations (CAO), it became clear: We were facing more systems issues that required deeper change. 

The interviews we started with were inspired by the recommendation from the CAO book “Chapter 8: Preparing the product group”, especially Area 2: “Understanding current reality”. This structured analysis became an important pillar for the transformation.  The parts from CAO we used were Individual Interviews, Heat Maps and Systems Modelling.  

The interviews were semi-structured and were carried out over about two weeks. Product Group Managers, Product Owners, Team leaders, Operations, Architects, Tech Leads, Line Managers were all asked about the current situation. The interviews were mostly 2-3 people in the same role at the same time. We decided not to use mixed groups. We had a hypothesis that different roles would have different views, and we didn’t want them to start discussing with each other instead of sharing insight with us.  

Our interview guide was very “open”. We started off with the question: “What are the biggest issues facing this product group?”. Then digging deeper into the issues that emerged.  

Different roles had different perspectives, yet most of them all converged on the same issues.  We summarized the issues into a list of 6 issues in the form of a report.  

Figure 1. Report.

 For this case study there are only two that I am going to cover.   

They are:  

• The Team Structure did not give the capabilities needed to deliver on the strategy. 

• The management matrix created unclear leadership authority and responsibility on multiple levels.  The matrix made it difficult to delegate necessary authority.  

I will dive more into detail on these in the next chapters.  

Systems Modelling for understanding 

Our systems modelling supported our understanding of these issues. We did some system modelling with managers on the topic of teams organized around the IT architecture and its negative consequence for interdependencies between teams. The result was a better understanding in management and a common understanding of the causes for some of our issues. We did the modelling on meeting chart post-its, but the model below shows the resulting causal loop diagram.  

Figure 2. Causal Loop Diagram Team Dependencies.

The key takeaway management got form the systems model is that: 

• Teams organized around components or functions increase dependencies 

• This gradually increases the complexity of the IT-architecture 

• Which again increases the need for more “component teams”. 

Management agreed that the team setup had a negative effect on their capability to deliver on their operations-centric strategy. They became convinced that structural change was required. 

Responsibility Assignment Matrix Workshop 

In order to have fruitful discussions about the issues surrounding unclear authority we also did a responsibility assignment matrix workshop.  (https://en.wikipedia.org/wiki/Responsibility_assignment_matrix).  My intention behind this exercise was not to have a well-defined matrix, but to help managers have a good discussion on the topic.  The matrix consists of a list of decisions in each row and each of the roles in the columns. Who makes these decisions?  

Figure 3. Responsibility & authority analysis results.

In pairs, the managers filled out the matrix and discussed disagreements.  There were three key takeaways from this exercise: 

• There were some responsibility conflicts between the line managers, product managers and team leaders.  

• For example, who was responsible for team performance and delivery? 

• Team leaders had unclear authority.  

• They either had very little authority or unclear roles. 

• Many decisions had to be made by the product group manager. 

• With the current setup, the product group manager felt it was hard to delegate certain decisions. 

This exercise created a common understanding in management for some of the issues stemming from the delegation of authority between roles in the product group. 

From Interview to Organization Design 

After seeing the results of the interviews and analysis, management approved of a more extensive transformation than what we initially had planned for. Even though we started small in our analysis, without any focus on strategy, we could extend into a bigger change later. 

At this point we saw the need to take a step back and look at the recommended approach by CAO. 

• What are the reasons for change? 

• What is the business strategy? 

• What organizational capabilities do we need to keep? 

• What organizational capabilities are missing and need to be developed? 

• What organizational design might build the capabilities? 

• Collaborate, Act, Reflect and Improve. 

Reasons for change were already mapped out.  

Time to look at the strategy! 

Phase 2: Design & Planning 

Employee Involvement Workshop

It was important for us during the transformation to include employees in order to increase ownership and reduce change resistance. We therefore had a big volunteer workshop with the following four topics.

Design Principles

We have made a set of design principles where employees could rate how much they agreed on each principle and give feedback. The principles were derived from CAO and general agile principles.  Some examples are:

• Teams should be cross-functional and able to deliver entire features.
• Code should be shared. No team owns code.
• As a general rule everybody should be part of a team.
• Teams should strive to be self-managing.

Figure 4. Our principles of change.

Feature / Component Heatmap

In this area, employees would map new features to components and come up with suggestions for grouping of features. On one axis you have a list of features and the other the different components of the IT architecture. The employees would map which parts of the architecture they thought would be needed to deliver the different features.  Some features would have similar components and could be categorized.

Ideally, we would want any team to be able to pick up any feature. Yet this was not realistic with the domain knowledge needed. Therefore we would use this heatmap to create as large areas as possible, while still getting some of the benefits of domain specialization.

In the example below the employees categorized the features into four categories. We would later use these categories to inspire the areas of value, product area organization and the backlog views.

Figure 5. Heatmap and Value Areas

Product Area Grouping

We would put up different suggestions to product area grouping. Employees would write pros and cons and give general feedback. In the following picture is a suggestion for having teams organized around the IT-architecture.

Figure 6. Teams organised around IT-architecture

While on the next picture shows a suggestion for organizing  teams around user processes.  

Figure 7. Teams organised around user processes.

Management Model Issues

In the management model part of the workshop employees, we would also do a minimized version of the responsibility authority matrix with the option of creating potential management setups. In the picture below you see one suggestion on how to solve management reporting lines.

Figure 8. Management reporting lines solution.

While the other shows the different responsibilities of leaders in the current setup. 

Figure 9. Management responsibilities.

Even though it is hard to know for sure, the management group felt that involving employees as early as possible in the transformation had a positive effect on change resistance.

Aligning Capabilities with Strategic Focus

It was important that we made sure managers were aligned on the strategy before doing any organizational redesign, we looked at CAO Guideline 7: Derive Required Capabilities from the Strategic Focus.   

It was important for the product manager that we keep the whole product focus when we looked at strategy and capability. The product supports citizens in all educational related activities, from applying to school to receiving diplomas. Institutions themselves also use this product for all their administrative needs.

But what was the products strategy? 

The product group has multiple clear strategy documents. The strategy documents state the following as effects they want with the continued development of the product.

• Increased data quality and accessibility
• Better opportunities for collaboration and efficiency
• Increased user-friendliness – better user experience with “easy to do right” approach in user interfaces, increased self-service and automation
• More efficient use of time and fewer manual operations
• Increased security and reduced risk of operational disruptions and downtime

I asked the management group to weigh the different centricities according to what they believed the strategy was about. This was the result.

• 60% Quality, Automation, Security and Cost-reduction (Operation centric)
• 30% Tailored user experience and branding (Customer centric)
• 10% Innovation and Time to Market. (Product centric)

Even though the product needs to have good user experience for citizens, it is mostly about avoiding disgruntled users and extra work for administrators. The strategy states that the modernization of the product should save the institutions money in the long run. The company mostly has a public monopoly on these kinds of services and does not need innovation and time-to-market to win over competitors.

Therefore, the managers agreed that they should be an operation-centric organization. This means that the strategy focusses on efficiency and the lowest total cost from the user’s perspective. The product should be standardized with good quality and excellent services, but it does not need to be the first to adapt to new technology nor tailor their product for specific user groups.  In the next two chapters we will see what that meant in practice.

Sidenote: An interesting thing happened during the discussions about strategy and centricity. Popular literature on modern agility (Marty Cagan, Team Topologies etc) give the impression that all companies need to “product organize” and be “user centric”. While some of these lines of thought are good, they can distort important discussions. Many employees meant that because of these books we shouldn’t be operations centric. Questions like “Does that mean we won’t have product teams? Does it mean we don’t care about the customer?”.  While good questions, they miss the point. Capabilities need to align with strategy. Not with popular literature and definitions. There is quite a big difference between Silicon Valley Startups strategy and public sector educational products in Norway.  

Moving on.

Redesigning Team Structure for Strategic Alignment

Understanding the strategy helped when we looked at the team structure. An overview of said structure is depicted in the figure below.

Figure 10. Team structure before the redesign.

All teams reported directly to the product group manager. The teams were of different “types”. The legend depicts the color of each type while the list below explains them.

• Product Centric Team: A team that is centered around a sub-product. Operates as their own product. The education proof team operated like its own product.
• User Group Centric Team: A team that is centered around a specific user group. The example here is the “Admission applicant team” which focuses on the applicant user group.
• Process Centric Team: A team that is centered around one or more of the student-administrative processes. “Student follow up team” focused on the processes when students had started school and until they finished.
• Component Team: A team that is structured around a technical component in the IT architecture. For example, the Admission Backend team which only worked on the backend component.
• Function Team: A team that is structured around a specific function. An example is the “process” team which contained domain experts.

Issues with this team setup

There were several issues this setup created for the product group. Most notably:

• Only a few teams aligned with the strategy. As we saw in the previous chapter, the strategy focused on ‘automation, cost reduction and quality’—suggesting an operation-centric model. However, most teams were actually aligned with user groups, products, or components instead. This created a major discrepancy between the stated strategy and actual team alignment.
• Multiple teams needed for delivery which created lots of coordination overhead.
• Many teams could not deliver on the most important features because the top items did not match their alignment, creating artificial work for those teams.
• Domain experts not part of the teams created low domain knowledge in teams.
• Distance from product management and teams was very high.

Any new team setup would need to address some of these issues. 

New team setup

To align the teams with the strategy we needed to become more operations centric. Since quality, automation and cost was the most important strategic driver, the team setup would be mainly focused on getting a cohesive group of teams working on a subset of important study administrative processes. In this article I will refer to these groups as product areas. In CAO these are referred to as value areas. 

We followed multiple of the CAO Guidelines while designing the new organization:

• Guideline 2: Decouple Unit Functions
• Guideline 3: Merge Units with Essential Interdependencies
• Guideline 5: Contain Reciprocal Task Interdependencies within the same unit. 
• Guideline 8: Create Conditions for Emergent Coordination

We also had some other important principles. (1) The groups should be small enough to be able to focus and specialize in the user domain while (2) large enough to make sure all areas would work on high priority items.  (3) Built in a way that allowed for the increase or decrease is in people or teams per section based on priority.

After multiple domain and ideation workshops, management agreed on creating three product areas, all process centric.

• All processes before admission. Like institution and education management.
• The admission process.
• All processes after admission, including education claims. (Proof of education.)

A small amount of people (About 10 out of 70) were organized into support units.  I will not go into details on these here. Our main principle was that these should be as small as possible in order to give most responsibility to the delivery units.

The full setup can be viewed in the figure below: 

Figure 11. Team structure after the redesign.

The entire product group has a common backlog with three different views, one for each product area. They also have shared yearly goals and metrics. This helps the organization stay aligned and avoid that each product area becomes their own isolated silos. Each group has one product owner that collaborates with the other product owners when dividing work between areas.

Each group has multiple teams all collectively working from the same backlog, sharing the same responsibility towards a common goal.

The Matrix, leadership authority and responsibility

The other big change we did was to stop with what was called “two-split leadership”. This meant we had line managers responsible for people and knowledge development and another reporting line responsible for product management. Here is the management setup before the transformation.

Figure 12. Management model before the redesign.

The first issue might be a cultural issue of Norwegian public companies. In the two-split management system in Norway it is normal that only the “line managers” are considered “real managers”. They have higher salaries, more authority and often more senior employees. This created an issue for product managers, who then had no authority over the people but the responsibility of delivering the product. Line managers had all the authority, but no responsibility for delivery. 

The observant reader will also see that there are even two-line managers reporting to an entirely different division manager. This also created some interesting situations where the product group manager would sometimes have to appeal to a line manager in a different division to get stuff done.

Even though this setup seems to be in accordance to Cao Principle 11: “Separate Line Management from Product Management” as the product group manager and the two product owners in the product management group did not have line manager responsibility. But the setup creates a stronger issue with Cao Principle 4: “Combine Authority with Responsibility.” As the authority and responsibility were split between the two “lines”. We therefore decided we had to find another way that would be able to follow both guidelines.

Was there another way to do this so that we could have senior managers contribute to the delivery of the product, while still having product management separated from line management? Our guiding principle became Combine Authority With Responsibility. 

We ended up removing the matrix all together putting the line managers in charge of product areas and all the employees within. See figure below:

Figure 13. Management model after the redesign.

This setup combines authority with responsibility for the line managers who were now ultimately responsible for their entire product area. Product management, people management and knowledge management. While this seems to go against CAO principle 11: “Separate Line Management” each product area has a dedicated product owner to do the prioritization of backlog items. This way the product owner would not have line management responsibility.   

Since Product Area Lead is responsible for delivery in the end, this setup requires good collaboration between her and the product owner. The product area lead would need to trust their product owners and their priorities.

Phase 3: Implementation

This article focuses on the design aspects of the transformation and not the implementation itself. I think it’s worth mentioning that we spent a lot of time trying to include all employees to create ownership and reduce change resistance.

The most important activities we conducted were:

• Workshops
  • On the topics of design principles, line management, product area groupings we had workshops where all employees could join and help make the designs.
• Classes
  • We did 3x 40 minutes volunteer online classes in modern development organization and roles created specifically for this audience. 
• “Town hall meetings” and “Gallery Walks”
  • Whenever we made any large decision, we had town hall meetings and “gallery walks”. The town hall meetings were mostly one way information and afterwards the gallery walk would be where people could look at sketches, discuss with managers and give feedback on the decisions.
• Optional 1 to 1 conversation
  • Everyone who wanted would have 1 to 1 conversation with their line manager about the change.
• Include workers union 
  • Unions are strong in Norway and including the union early as part of the work was crucial for the success.
• Registration form for what product group you would like to work in.
  • People would be able to have a choice in what product groups they would like to work in.

Reviewing these activities in more detail is topic for another article.

Conclusions and results

Even though the transformation was a lengthy process, it has had clear positive results. 

Product Area Manager Feedback

One could say that one of the biggest changes in the transformation is the role of the Product Area Managers who were the former line managers. One manager reports the following on the results of the change:

• Significant improvements in role clarity when it comes to leadership roles. 
• Easier to give clear priorities, avoid scope creep and reduce work in progress. 
• Some teams have visibly better delivery speed. 
• Faster decision-making.
• More focus on user outcomes and the domain, than internal components and coordination.

The manager attributes this to removing the matrix and assigning each product area one senior manager with full responsibility. This indicates that the following guidelines have had an important impact on the effectiveness of the organization:

• Guideline 1: Organize into Product Groups
• Guideline 4: Combine Authority with Responsibility.
• Guideline 11: Separate Product Management from Line Management

She also remarks that grouping teams together in accordance with the users processes has created better communication between the product group and their users.  It has also improved internal communication and coordination.

The manager states that it was important that we had clear responsibility divided between the product areas to get people onboard. Yet now they already see that that division creates some sub-optimization in priorities. There might be a need to reevaluate this division or find more fluid ways of dividing work between product areas.

Product Group Manager Feedback

The product group manager was one of the proponents for getting rid of the matrix. She felt that the dual reporting lines created an atmosphere of fuzzy communication and unclear priorities.

When asked about the effect she noticed on the transformation the message was clear.  All the issues she felt with the matrix were gone.  This supports Cao Guideline 11 strongly. She says:

“Communication and collaboration work a lot better. It feels like we have become a more cohesive product group.”

She also says that since she now has product area managers with clear authority and responsibility, she has been able to give the areas more autonomy. 

For improvement she also sees that there is now a risk for the product areas to start isolating themselves and optimizing their own area at the cost of the other areas. This risk should be addressed by the increased collaboration between product owners.

Conclusions

In this case study we followed a product group in SIKT when they were combatting the following two issues:

• Their Team Structure did not give the capabilities needed to deliver on the strategy.
• Their management matrix created unclear leadership authority and responsibility on multiple levels.  The matrix made it difficult to delegate necessary authority. 

Based on these issues, the product group started a larger transformation lasting almost a year. The most important changes were:

• Removing the dual reporting lines and management matrix all together.
• Establishing three product areas based on their operation centric strategic foci. 
• Assigning senior managers to each of these product areas.

The removal of the matrix has so far been unanimously welcomed by management. While the product areas have given focus and clearer priorities, they also run the risk of isolation and sub-optimization. This is something for the product area management to look out for.

Out of all the changes, the removal of the matrix and establishing product areas with senior management has been the most successful.  Using CAO as our guide, focusing on the design guidelines, we have been able to create a more versatile and responsive organization with better clarity and the necessary autonomy to handle tomorrows challenges.