Separate User org and Management

docs/workflows/best-practices-organization.md

@@ -8,12 +8,13 @@ The purpose of this document is to provide concrete and actionable guidelines on
 
 ## Three stakeholder groups in a hybrid model
 
-Typically, nobody in an organization is opposed to building quality software. Rather, investing in software quality often loses out to other topics, typically adding features and fixing bugs. The shift that needs to take place is that organizations allow for a fair competition to take place between feature work and technical improvements. 
+Typically, nobody in an organization is opposed to building quality software. Rather, investing in software quality often loses out to other topics, typically adding features and fixing bugs. The shift that needs to take place is that organization arrive at a way of working that allows for a fair competition to take place between feature work and technical improvements. 
 
 Having consulted with many organizations, we have identified three stakeholder groups that need to be involved to make this shift and achieve high quality software, structurally. These are:
 - Teams
 - Engineering leads
-- Management
+- The User Organization
+It is the role of Management to ensure that these stakeholder groups arrive at a way of working that is acceptable to each of them and the organization as a whole.
 
 Making the shift is not just a matter of 'the business should allow us to work on improvements instead of pushing for features'. There is a responsibility from teams and engineering leads to properly shape and quantify the work they think needs to be done so a fair assessment can be made. Also, teams need to accept the need for standards. In areas like security and legal, it is not practical or desirable for individual teams to assume full responsibility for these aspects. 
 
@@ -27,17 +28,22 @@ While our terminology is pretty generic, each organization is different and some
 
 Of these groups, **teams** are typically the easiest to identify, because they exist as such. 
 
-**Management** can be harder because many organizations, especially larger ones, have multiple layers of management and not all of them are relevant in our context. Typically though, management represents the (strategic) organizational goals and has a budget responsibility. They are accountable for the outcomes of software development and as such, are concerned with topics like cost, speed and risk. While this accountability ultimately lies with a CEO, the concerns can also be represented by a product owner or project manager. Put differently, while 'management' suggests people higher in the hierarchy, this is not a hard requirement for this group. We are not looking for 'the boss', we are looking for people who represent the concerns mentioned.
+The **User Organization** consists of everyone who is in some way affected by what the software does, ranging from actual users to managers who are responsible for a process supported by the software and, not unimportantly, have to pay for it. Often, this group is referred to as 'the business' but we are not a fan of that term because especially in commercial organizations (often referred to a 'businesses') it suggests a certain hierarchy between the user organization and the technology organization that historically has not been helpful in achieving successful outcomes in general and high-quality software in particular.
+Obviously it is not practical or desirable to involve the entire user organization in this process. Often, the user interests are represented by a product owner or project manager. 
 
 **Engineering leads** are typically the hardest one to identify because it is the least established of the three groups and exists in various forms and to varying degrees. Engineering leads are typically involved in (higher-level) solution design, technology choices or security analyses and policies. Job titles may include tech lead, team lead or architect. Engineering leads may exist within teams and organize virtually through Communities of Practice, Guilds or Chapters. In other cases, separate engineering lead roles or teams exist, such as enterprise architects, security specialists or Centers of Excellence. elsewhere in the documentation we refer to engineering leads as architects. 
 
+**Management** are the people whose main interest is that 'the whole thing works'. They facilitate the interaction between the different stakeholder groups and ensure that decisions are made and ties are broken. As such, they are found higher up in the hierarchy and since software quality is typically a technology concern, we primarily see technology managers in this role, like engineering managers, head of software development or sometimes a C-level role like a CTO. 
+
 ### The role of each group
 
 The role of **teams** in the creation of high quality software is obvious: they actually create it. They have three main instruments to leverage their craftsmanship when it comes to creating quality software: peer reviews, tests that run in the pipeline (both functional and non-functional such as Sigrid CI) and hygiene features present in the IDE. The main inputs are quality requirements set by the team themselves, engineering leads and management, including objectives set in Sigrid. In reaching their quality goals, teams may identify impediments that they cannot address themselves (or that are not effectively/efficiently addressed by the team, such as a change to a shared repository that affects other teams as well). These are communicated to engineering leads or management for resolution. 
 
 **Engineering leads** address engineering challenges that are bigger than a single ticket, may transcend teams and have the ability to significantly improve the quality of the software (or ensure that software-to-be-built is of good quality) but are not directly related to feature work. Examples include threat modelling and subsequent mitigations, major refactoring/rearchitecting, but also agreeing on standards for non-functional requirements and how to implement them. Inputs for this group can be concerns raised by teams that they cannot address themselves, standards that need to be met, operational problems (e.g. poor performance) or antipatterns spotted by engineering leads (team leads, tech leads, architects) themselves.
 
-**Management** often has a black-box view of technology: organizational needs go in, value-adding tech comes out while cost and risk need to be controlled. They want quality software as much as anyone else as long as it can be balanced against cost and organizational needs. They should be open to technical improvement ideas put forward by teams and engineering leads but also challenge them to articulate the cost/risk/benefits of their proposals.
+The **User Organization** often has a black-box view of technology: user needs go in, value-adding tech comes out while cost and risk need to be controlled. They want quality software as much as anyone else as long as it can be balanced against cost and organizational needs. They should be open to technical improvement ideas put forward by teams and engineering leads but also challenge them to articulate the cost/risk/benefits of their proposals.
+
+**Management** facilitates all this, ensuring a structure exists in which stakeholder groups meet and can put forward their needs and concerns. They should also keep an eye out for concerns that may fall through the cracks, such as open source license risk, and involve relevant people such as a Head of Legal. They provide the escalation path for all stakeholder groups and remove impediments. 
 
 ### Towards a healthy engineering culture