The Adaptive Governance Framework V.1

[Jakob Anker]

The Adaptive Governance Framework

An extension of The Governance Topology

Table of Contents

1 - Introduction 2 - Disclaimer 3 - Ideation types 4 - Demand Dimensions 4.1 - On Normal and Minor demands 4.2 - On Capacity, Skill, Citizen development, and Demant Types 4.3 - Example: Scoring Demands 5 - Solution Dimensions 5.1 - On Complexity 6 - The Adaptive Governance Framework 6.1 - Demand Management 6.2 - Complexity Triaging 6.3 - Normal Solution Documentation 6.4 - Dimension-dependent Authorization 6.5 - The Technical Forum 6.6 - Development Management 7 - Framework Integrations 7.1 - Business Smart Customization 7.2 - Technical Debt Management

1 - Introduction

Welcome, my friend.

 Previously, I introduced you to The Governance Topology, which is how I envision the next evolution of governance work. It sets out "to demystify and provide an actionable framework for the continuous maturation of the decision framework that is set in place to monitor, guide, and control a platform's changes."

You might think of The Governance Topology as the backbone, the structure on which we can build our processes. This document will provide you with precisely that.

When we consider platform changes, it starts in ideation and ultimately ends with deployed updates.

Historically, the deployment and planning of changes have been well-established disciplines, one we know as Change Management.

The beauty of Change Management is that it recognizes that not all changes were born equal; through the constitution of Change Types, we understand that not all change processes should be identical. Depending on the Complexity, risk, and historical success of specific types of changes, we expect some changes to fall under the 'Standard' change type. Though these require less rigor and governance, they should still be tracked and managed.

Change Management, however, only provides us with one portion of the story of platform changes.

Platform changes start with an idea. The Idea is triaged and promoted to a demand, which is further qualified. If the qualified demand is in alignment with strategic intent and budget, it is further promoted. Now, we are talking about Solutions.

To me, a logical question would be: can we achieve similar context-based processes outside of the change management realm?

Here, I will propose a way of defining platform changes in their earlier stages, before change management, through a lens like that of the Standard vs. Normal type dichotomy.

2 - Disclaimer

This document and its contents are provided as-is. They are not affiliated with, endorsed by, or officially connected to ServiceNow. The views, opinions, and information expressed in this document are those of the author(s) and do not reflect ServiceNow's official position or policies.

3 - Ideation Types

Traditionally, ideation is a democratic process where all users can propose platform changes based on their experience and input.

In this document, when defining entity types and dimensions as Demands and Solutions, we are targeting specific governance flows and authorities.

The Idea arrives as something raw that is to be processed and qualified, and by that nature, it makes less sense to label any types.

Therefore, while we might be able to argue for different types of ideas when considering the source of ideas, this document will spend less time on this topic.

4 - Demand Dimensions

The following table explains the dimensions of a demand that needs to be qualified before it can be processed correctly within the Context-based Governance Framework.

Dimension	Attribute	Description	Example
Strategic alignment	Defined	We know how the demand is aligned with business outcomes	•       Cost reduction
	Undefined	We do not know how the demand is aligned with business outcomes. This constitutes a risk. 'Keeping the lights on' is an option for break-fixes, which is a strategic imperative in itself.	•       Undefined
Reach*	Minor	5 percent of the user base	•       -
	Medium	10 percent of the user base	•       -
	Large	50 percent of the user base	•       -
	Total	100 percent of the user base	•       -
Impact	XS (0.25)	Minimal impact on business outcomes is likely	•       Minimal impact on (cost reduction and/or great employee experiences) likely
	S (0.5)	Low impact on business outcomes is likely	•       Minimal impact on (cost reduction and/or great employee experiences) likely
	M (1)	Medium impact on business outcomes is likely	•       Minimal impact on (cost reduction and/or great employee experiences) likely
	L (2)	High impact on business outcomes is likely	•       Minimal impact on (cost reduction and/or great employee experiences) likely
	XL (3)	Massive impact on business outcomes is likely	•       Minimal impact on (cost reduction and/or great employee experiences) likely
Confidence	Percentage score	0-100 percent confidence that the remaining dimensions are accurately defined.	•       80%
Type	Enhancement	Addition or change to an existing feature or product.	•       Extension of an existing flow or business rule.
	New feature or product	Net new product, such as a new product installation or a smaller feature.	•       Customer Service Management •       New Process Automation Design
	Operational	Needed to keep the lights on	•       System upgrade
	Security & compliance	Needed to comply with laws and standards	•       Data Privacy product demand
	Infrastructure	Needed to optimize the hardware (physical or not) used to deliver services	•       New hosting solution •       New rack server

 Table 1: Demand Dimensions used to determine the portfolio governance functions and authorities needed per planning item.

4.1 - On Normal and Minor Demands

The 'Normal' demand types will likely be the most used types.

As with change management, we have two types of entities (e.g., standard VS normal) here under the names Minor and Normal.

We make distinctions between normal demands, which require normal levels of governance, and minor demands, which require less scrutiny. If the proposed demand is not minuscule or of a standard nature (Minor), then we would want to see a normal demand process for it.

To elaborate on Normal demands, these can be of very different degrees of importance, size, and Complexity.

The dimensions of the individual demand (Strategic alignment, reach, impact, confidence, etc.) will set the individual demand apart in the demand process, which remains the same.

4.2 - On Capacity, Skill, Citizen Development, and Demand Types

When determining the Complexity of a demand and its related solution design, it makes sense to discuss the available skills and capacity thereof when promoting new demands to a roadmap.

Additionally, we might want to consider standard types of demands as they may relate to known Citizen Development scenarios (e.g., new catalog items, app engine studio builds, etc.) and have separate demand types and processes for this where prior implementation success, Complexity, and effort needed by central governance is more in focus than the 'normal' governance approach as the citizen provides capability and capacity.

4.3 - Example: Scoring Demands

Let's say that we have two demands, each for a specific product adoption: Employee Center VS Walk-up Experience.

How do we know which demand to prioritize over the other?

Demand management would try to normalize their value as an individual contribution to the larger strategic direction and business objectives, through industry best practices for assessing demands based on standardized parameters.

In this framework, we are leveraging RICE.

Here, the value of adopting a specific product can be gauged by assessing adoption reach, impact on business objectives, and effort associated with its full adoption.

 Figure 1: The Value triangle. Shows how value is derived and supported through different adoptions and activities.

In the above scenario the given enterprise might want to position the Employee Center as the more valuable demand for product adoption. The "value" does not mean anything in itself, but because we are using the same formula and standardized parameters across our demand candidates we can use the metric as a starting point for out portfolio planning exercise when planning a roadmap.

Using such a framework, we ensure we understand how an activity supports the value we are seeking while keeping our progression towards our targeted value measurable.

5 - Solution Dimensions

A demand may eventually be prioritized to become a solution proposal. It remains a solution proposal until it is accepted as a deliverable to be released into production.

A solution proposal will start as little more than a business-justified idea and gradually evolve into an updated set ready to be deployed.

The Solution Dimensions can be expressed as follows:

Dimension	Attribute	Description	Example
Complexity	Small	Simple change	·          New field ·          Simple property change
	Medium	Substantial change	·          New automation ·          New reporting
	Large	Extraordinaire change	·          Customization of core logic ·          New application
Performance	Significant impact possible	-	·          Changes to queries. ·          Related list added to form ·          Changes to client-side logic
	Significant impact unlikely	Non-performance related change	·          A new field. ·          A simple scheduled job outside of peak business hours
	Undefined	Risk if not defined.	·          Change is driven to circumvent governance.
Upgradeability	Significant impact possible	The platform change customizes standard objects or introduces similar features to those of SN.	·          Changes to standard flow or business rule. ·          Introduction of a separate and custom ITSM task (e.g., custom change management outside of the SN standard product)
	Significant impact unlikely	Changes that do not block upgrade-driven changes. The platform change adds a new object that may or may not be related to a standard object. Example: we can add a business rule to established products as Incident Management, without impacting upgradeability (unless it is competing with existing standard objects)	·          New field in a table. ·          New table. ·          New business for ITSM tasks.
	Undefined	Risk is not defined.	·          Change is driven to circumvent governance.
Process	Significant impact possible	The change is likely to impact the way the business operates.	·          Agentic AI ·          New state ·          Process Automation Designer steps
	No significant impact is unlikely	The change is likely to impact the way the business operates.	·          Report ·          New optional field ·          Back-end logic
	Undefined	Risk is not defined.	Change is driven to circumvent governance.
Security & compliance	Significant impact possible	The change may put the company at risk with security and compliance regulations.	·          PII shared with a new business application or process.
	No significant impact is unlikely	The change is not likely to constitute a risk.
	Undefined	Risk is not defined.	Change is driven to circumvent governance.

Table 2: Solution Dimensions used to guide the technical governance functions and authorities needed per planning item.

5.1 - On Complexity

For further examples of what different platform changes might relate to in terms of Complexity, please refer to the section on Business Smart Customization.

6 - The Adaptive Governance Framework

As with standard and normal changes, we only want specific paths for specific types of solution proposals. As described in The Governance Topology, we are not necessarily talking about what Governing Functions (e.g., Technical QA forum); rather, we are interested in determining what Authorities we should consult depending on the dimensions of a solution proposal.

Figure 2: The high-level context-based governance framework, which will be expanded below, using the dimensions of a demand and solution design.

In the following section, we will expand on the above basic process diagram, moving from a prioritized demand until it is ready for testing.

When applicable, the individual sections of the diagram will be expanded in their related subsections below.

6.1 - Demand Management

Figure 3: The demand management expanded. It is not supposed to capture the entirety of demand management; rather, it is focused on how the dimensions of a demand affect the type of flow it should follow.

6.1.1 - Authorities

A governance function must have the vested authority to

• Align demands with strategy (DEMAND ALIGNMENT TO STRATEGY)
• Qualify and score demands (DEMAND QUALIFICATION)
• Prioritize demands for further development (DEMAND PRIORITIZATION.

6.1.2 - Authority Thresholds

For DEMAND PRIORITIZATION authority

You might employ a threshold where the demand manager has a lower degree of Demand Prioritization authority than the demand board. The demand manager might be able to approve demands that are of lesser significance and impact than others (e.g., minor VS normal).

The dimensions of the demand could be used to decide, based on scoring criteria, whether we are dealing with a normal or minor demand.

6.2 - Complexity Triaging

At its core, we want to ensure that we govern changes that need governance, and only to the degree necessary.

Therefore, an initial screening of prioritized demands takes place where rough solution proposals are assessed.

Here, we want to establish if we are dealing with a small complexity change or not.

The outcome of this screening decision defines the level of documentation needed before we arrive at the Technical Forum (i.e., a core Technical Governance Function where it is decided whether a solution design is ready to be developed).

As a rule of thumb, if any of the aforementioned solution dimensions (refer to 'Solution Dimensions') are likely to be significantly impacted, then we have a Medium+ complexity solution proposal.

Figure 4: Complexity triaging. At its core, we are looking to determine the right level of scrutiny in our governance per planning item. Considering the level of Complexity related to a planning item helps us route it.

6.2.1 - Authorities

A governance function must have the vested authority to

• Qualify solutions in terms of their dimensions (SOLUTION COMPLEXITY TRIAGING)

6.2.2 - Authority Thresholds

The SOLUTION COMPLEXITY TRIAGING authority

would be appointed the tech leads where thresholds make less sense to discuss.

Should there be an especially complex solution, it would be discussed through appropriate channels of demand management for re-prioritization if new/unforeseen dimensions of a solution are identified.

6.3 - Normal Solution Documentation

In the case of a Medium+ complexity solution proposal we should leverage the Normal Solution Design Template (refer to appendix). Else, we leverage a Light Solution Design Template.

Figure 5: Inside complexity triaging, we can expand on the Normal Solution Documentation and its two steps.

6.4 - Dimension-dependent Authorization

The solution documentation should include the Solution Design Dimensions, which, if likely to be significantly impacted, would require different processes and authorizations to be in place.

If the dimension is undefined, then it poses a risk that is up for the Technical Forum to decide if they will own it, or if they will demand a definition of no impact likely or significant impact likely.

Figure 6: Finally, the main component in the medium+ complexity flow, the dimension-dependent authorization. It provides a standard framework for when to do what, depending on the dimensions of the given planning item.

6.4.1 - Authorities

A governance function must have the vested authority to

• Approve platform changes when general aspects of the platform (e.g., performance) are likely to be impacted by a solution (PLATFORM CHANGE)
• Approve customizations when a solution is likely to have a significant impact on a system's upgradability (CUSTOMIZATION APPROVAL)
• Approve changes to processes when a solution is likely to impact the flow of a business process (PROCESS CHANGE)
• Approve a solution based on its likelihood to impact security and compliance regulation (SECURITY AND COMPLIANCE STANDARDS)

6.4.2 - Authority Thresholds

The PLATFORM CHANGE authority

is typically vested in the platform owner. The platform owner is typically close to a center of excellence, Technical Forum, and general platform changes, whereas it is likely unnecessary to vest degrees of PLATFORM CHANGE authority to 'lesser' governance functions.

As an example, you might implicitly consider that an implementation partner has some of this authority, as different ways to implement a specific solution might slightly change how much the final solution impacts the platform's performance.

The CUSTOMIZATION APPROVAL authority

is typically vested in platform owners and product owners, and you would need these people to accept technical debt before continuing.

Should there be an especially complex solution, it would be discussed through appropriate channels of demand management for re-prioritization if new/unforeseen dimensions of a solution are identified.

The PROCESS CHANGE authority

will be placed at the Process Owners responsible for the end-to-end business process. As we are in business, its normal escalation chains would follow. Final escalation points would likely be C-level. No need to define further in here.

The SECURITY & COMPLIANCE STANDARDS authority

would be vested in security officers. They have a natural tie to business. As we are in business, its normal escalation chains would follow. Final escalation points would likely be C-level. No need to define further in here.

6.5 - The Technical Forum

Now, we have completed our Complexity—and dimension-based due diligence. At this stage, we are ready to have the solution design, as well as its dependent processes and authorizations, reviewed before approving it for further development.

Either the pre-approvals have already been attained (e.g., if a process is likely to be significantly impacted by a process change, we would want to obtain the Process Owners' authorization before accepting a design), or the relevant authority is included in the Technical Forum session to assess the proposed impact.

This is what sets apart a mature governance process: we can triage and process solution proposals efficiently, thereby understanding what information and authorization we need to bring to the Technical Forum (i.e., the Design Authority-wielding Governance Function).

6.5.1 - Authorities

The Technical Forum would wield the authority to approve platform changes, as they have been deemed to comply with necessary processes and prerequisite authority approvals (PLATFORM CHANGE)

6.5.2 - Authority Thresholds

The PLATFORM CHANGE approval

is typically vested in the platform owner. The platform owner is typically close to a center of excellence, Technical Forum, and general platform changes, whereas it is likely unnecessary to vest degrees of PLATFORM CHANGE authority to 'lesser' governance functions.

6.6 - Development Management

When we have developed the updates related to the agreed solution design, we must stop and consider (read: re-triage): is this still the same level of Complexity as originally designed, or has it changed?

Unexpected circumstances during development may necessitate a change in the technical design, which can impact how the Solution Dimensions take shape and ultimately impact the platform.

If any Solution Dimension has been significantly impacted beyond what we originally intended, we must re-engage with the correct authorities and processes to obtain a green light before proceeding.

This additional authorization occurs in the Technical QA Forum, the post-development governance function aimed at reviewing update sets that are either complex or whose design has changed significantly to impact a solution dimension.

Depending on the impacted solution dimension, tech leads and applicable authorities will board the Technical QA Forum.

Figure 7: In the development management stage, we again refer to the solution's complexity, and depending on changes to it, we might send it to Technical QA.

6.6.1 - Authorities

A governance function must have the vested authority to

• Develop the required solution (DEVELOPMENT)
• Qualify that the developed solution of medium+ Complexity follows the technical standards (TECHNICAL STANDARDS)
• Qualify solutions in terms of their dimensions (SOLUTION COMPLEXITY TRIAGING)

6.6.2 - Authority Thresholds

The DEVELOPMENT authority

will be vested in accordance with the operating model of choice.

It is normal to partner with Implementation-focused vendors. Ideally, we would want the actual enterprise to wield the ultimate DEVELOPMENT authority, hereby becoming the final escalation point for complex deliverables, where an implementation partner would have a degree of DEVELOPMENT authority. Here, you might make softly defined thresholds for when an escalation needs to happen or follow the dimensions of the solution (e.g., Impact on performance, upgradeability, etc.) to determine when an escalation should happen.

The TECHNICAL STANDARDS authority

is vested similarly to that of the DEVELOPMENT authority, though with a distinction that we would appoint specific technical leaders for this authority rather than organizations. In the case of an especially complex solution, it should be discussed through appropriate channels of demand management for re-prioritization, when new/unforeseen dimensions of a solution are identified.

The SOLUTION COMPLEXITY TRIAGING authority

would be appointed as the tech leads, where thresholds make less sense to discuss.

Should there be an especially complex solution, it should be addressed in accordance with the appropriate channels of demand management for re-prioritization if new/unforeseen dimensions of a solution are identified.

7 - Framework Integrations

7.1 - Business Smart Customization

Business Smart Customization is a decision framework developed by ServiceNow to facilitate standardized approaches for approving customization based on its Complexity and business value.

This removes the volume of a voice and the stars on the shoulders of the speaker when it comes to prioritizing and approving customization work. Instead, it allows for a standard apparatus based on standard parameters and precedence (previous decisions on similar types of customizations that we proposed).

Over time, as the framework is used, more and more decisions will build up the log of decisions per scenario (e.g., adding fields, states, integrations, etc.), which the Governance Functions can leverage to expedite future customization requests.

The tables below show columns that apply to business-smart customization decisions.

Scenario	Prior decisions	Min. Business Value	Complexity	Can Impact
				Upgrade	Performance	Manageability	Process
Modification to form layout or design	<URL>	XS	XS	False	False	False	False
Add fields and/or UI policies to forms	<URL>	XS	XS	False	False	False	False
Build a simple custom integration	<URL>	XS	XS	True	False	False	True
Extend an existing table (e.g., cmdb_ci) with new fields only	<URL>	XS	XS	False	False	True	False
Extend an existing table (e.g., task) with some scripting	<URL>	S	S	True	True	True	False
Extend an existing table (e.g., task) as the basis for a different application	<URL>	S	S	False	False	True	False
Change the state choice list (e.g., modify the incident process)	<URL>	S	S	False	True	True	True
Build a new scoped application	<URL>	M	M	True	True	False	False
Build a new global application	<URL>	L	L	True	True	True	False
Change baseline business rules (e.g., modify the SLA process)	<URL>	L	L	True	True	False	True
Build complex custom integration	<URL>	XL	XL	True	True	True	True
Use the incident table as is for a different use	<URL>	XL	XL	True	True	True	True
..	..	..	..	..	..	..	..

Attributes

As you may have noticed, the Business Smart Customization attributes mirror the Solution Dimensions used in the governance process. This is intentional and makes the synergy between the decision framework and the governance process clearer.

Scenario

A generic type of platform change that may apply across different types of changes (e.g., build a complex custom integration)

Prior Decisions

URL references to previous solution designs or decision documents detailing related platform changes are used as a baseline (i.e., precedence) to assess future solution proposals that fit into the same Scenario.

Min. Business Value

T-shirt size for the minimum business value needed for a custom solution design to be accepted by the CUSTOMIZATION APPROVAL authority.

T-shirt sizing is a way of normalizing values, and it can be helpful to anchor normalized values in practical examples. The logging of prior decisions is one way of doing this, and the addition of examples (e.g., number of impacted users, impact on business objectives, etc. might be another. I recommend mirroring the RICE-scoring used in the demand management section for consistency. Copied below for ease of reading:

Dimension	Size	Description	Example
Impact (on Business Objectives)	XS	Minimal impact on business outcomes is likely	•       Minimal impact on (cost reduction and/or great employee experiences) likely
	S	Low impact on business outcomes is likely	•       Minimal impact on (cost reduction and/or great employee experiences) likely
	M	Medium impact on business outcomes is likely	•       Minimal impact on (cost reduction and/or great employee experiences) likely
	L	High impact on business outcomes is likely	•       Minimal impact on (cost reduction and/or great employee experiences) likely
	XL	Massive impact on business outcomes is likely	•       Minimal impact on (cost reduction and/or great employee experiences) likely

Complexity

The complexity attributes describe the level of Complexity that we would expect to see when customizing a specific scenario.

Similarly, we can use the complexity definition of the Solution Dimensions:

Dimension	Attribute	Description	Example
Complexity	Small	Simple change	·          New field ·          Simple property change
	Medium	Substantial change	·          New automation ·          New reporting
	Large	Extraordinaire change	·          Customization of core logic ·          New application

Can Impact...

The can Impact attributes mirror those of the Solution Dimensions. The decision tree for when to do what has already been built in this section and will not be repeated here.

The exercise in Business Smart Customization is not to repeat the exercise, but rather to consider if the relationship between DIMENSION/IF/THEN applies here, and whether they need an update in general. Additionally, a core activity is to build the decision log to expedite future decisions based on common scenarios.

7.2 - Technical Debt Management

In all honesty, few enterprises have had proper discipline around when to customize and how to track and manage technical debt, as this implies a governance maturity that few were able to boast at the time of SN's inception.

We must remember that SN is a relatively young platform, and the standards and ways of working have been emerging alongside it.

Therefore, it is to be expected that a discipline as technical debt management has suffered in the rapid pace of innovation and demand around the SN platform.

A symptom of the lack of technical debt management is the increasing amount of re-platforming and standardization programs happening. It is quite normal to experience a re-platforming, and I would almost advise any enterprise that has had SN for an extended period to seriously consider whether they might want to do just that.

A decision that, of course, is not to be taken lightly, and which comes with its own complex assessment and process. Regardless of where you are in your platform life cycle, it is never too late to incorporate good practices.

Technical debt management is not a complicated framework to integrate.

It can be boiled down to:

• Track technical debt across all relevant sources.
• Manage each technical debt item at a set frequency.
• Always look for opportunities to escape technical debt.

When we have assessed a solution design that implies customization and decided to continue with its implementation, we should track it as technical debt.

The table below shows columns that may apply to your technical debt register.

ID	Title	Description	Justification	Active	Status	Source	Type	Cost Center	Solution design
XX	Custom data model in CSM	Changes to the before query business rules and script include	Needed a m2m visibility model which is not supported OOB.	True	Sustain	Development	Customization	CCXXXXX	<URL>

7.2.1 - Attributes

ID

Unique identifier

Title

Debt title

Description

Debt description

Justification

Justification for why we incurred this technical debt needs to be specific and preferably rooted in a business context. This will make it easier to assess whether the debt is still justified in future releases.

Active

True (choice option)

The technical debt is live in our system.

False (choice option)

The technical debt is in our system, though not live (e.g., inactive business rule).

Status

New (choice option)

The technical debt has been accrued, and no regular debt assessment cadence has occurred since. Once a debt assessment is set to happen again, we would want to move the status from New to one of the below.

Sustain (choice option)

We intend to keep the technical debt despite the possible standard solutions available. The justification should detail why.

Innovate (choice option)

We want to expand our technical debt, as continuing down this path is valuable to our business.

Decommission (choice option)

We are actively looking for paths to replace the technical debt with standard solutions.

Exit (choice option)

We have begun the decommissioning.

Complete (choice option)

The technical debt has been removed.

Source

Health scan (choice option)

An acknowledged finding from the health scan that we intend to address.

Development (choice option)

A developed platform change (e.g., updates set with custom objects).

Lift-and-shift (choice option)

Remnants from a previous platform that have been lifted onto the SN platform. Often happens do appease onboarding stakeholders or to match expected timelines.

Complex configuration (choice option)

An identified architecture that in itself is not a customization but constitutes a challenging and non-best-practice solution (e.g., not using script includes for repeated logic, not using templates and layouts for repeated email content, not using models for repeated instances, etc.)

Cost Center

We always forget that customization is ultimately a technical debt that someone needs to repay. If we do not agree on who owns the technical debt and what is owed, then we cannot expect any business to carry the debt in the future once a standardization option has been identified.

It is much better to get an early acknowledgement from the business that a) the platform is stretching to accommodate valid and justifiable requirements, and that b) ultimately the bill is expected to come back to the business cost center when a standard option is available.

 

7.2.2 - On The Price of Debt

When appointing a cost center to an incurred technical debt, it is logical to ask, "OK, but what do I owe?"

Here, we can imagine debt in different metrics:

• A price tag.
• Spent hours.
• Points.

To repay the debt, we can also consider different models.

Either we:

1. Repay the debt once a suitable standard candidate has been identified, or
2. We continuously pay back into a pool (money, hours, or points) that is used to standardize across all cost centers.

Option b) has the benefit of establishing a system and mindset early. You opt into the technical debt by opting into a crowdfunding model to standardize the platform continuously, which pays dividends to all onboarded business units through a healthy and agile platform.

Credits

A special thanks to...

@dellapfaffle for in-depth sparring and ideas for the framework.

More content by Jakob Anker Nielsen

Connect With Me