Feature: Team and Organisational Design Principles

TeamForm can be used to implement a range of operating models and organisational frameworks as outlined here https://www.teamform.co/solutions-for-teams .

TeamForm has a feature called principles, which can be used as guardrails when transitioning to, or as part of, cross-functional, agile or lean ways of working methods.

Teamform has some predefined principles grouped into principle sets that can be configured to meet a particular use case.

Principle sets can be created to accommodate different team archetypes (e.g. cross-functional, flow-to-work, service, platform, etc).

Examples of principles and principle sets

Individual/Role/General Principle Set

• X layers from the CEO

• Role diversity (individual) and total role diversity (organisation)

Team/Squad Principle Set

• Between X & Y members (e.g. 5-9), full or part-time

• Location e.g. same city, same building, same floor, timezone, if distributed - no more than X locations

• Specific and/or dedicated roles included e.g. Scrum Master or Product Owner, etc

• Number of line managers

Group/Tribe/'Team of Teams' Principle Set

• Maximum number of individuals e.g. 150

• Maximum number of teams/squads

• Specific and/or dedicated roles e.g. Tribe Lead, Group Performance Lead, etc

Domain/Business Unit Principle Set

• Maximum number of individuals e.g. 500

• Maximum number of groups/tribes/'teeam of teams' e.g. 7

Configuring Principles

Principles are enabled in a workspace by default, but can also be toggled off via settings / workspace feature toggles

Principles sets are defined via Settings / Principle sets using a JSON file.

The key fields referenced in a principle set are as follows:

“id” - a unique id string.

”name” - a name for this principle set (string)

“suitableGroupTypes”: a single team type (e.g. “squad” or a list of team types e.g. “squad”, “tribe”, “COE”

Default principle sets can be defined per team type via Settings / Org Structure type config. Select a team type, then choose a preferred principle set for that team type.

JSON parameters for Principles:

Member Count

^parameter maxMembers(optional), minMembers(optional)

^title Should consist of no more than ${maxMembers} direct members.

Should consist of at least ${minMembers} direct members.

Should consist of between ${minMembers} and ${maxMembers} direct members.

      {
          "type": "MEMBER_COUNT",
          "args": {
              "maxMembers": 10,
              "minMembers": 5
          }
      }

Total Member Count

^parameter maxMembers

^title Should consist of no more than ${maxMembers} direct and indirect members.

    {
        "type": "TOTAL_MEMBER_COUNT",
        "args": {
            "maxMembers": 150
        }
    }

Spread

^parameter maxTeamsPerMember, teamType

^title Each member should be in no more than {maxTeamsPerMember} teams.

  {
        "type": "SPREAD",
        "args": {
            "maxTeamsPerMember": 1,
            "teamType": "design"
        }
    }

Role Spread

^parameter role, roleDisplayName, limit, teamType, teamDisplayname, roleTagType, roleTagAttribute

^title ${roleDisplayName} should work in no more than ${limit} {teamTypeDisplayName}

    {
        "type": "ROLE_SPREAD",
        "args": {
            "role": "(.*product.*owner)",
            "roleDisplayName": "Product Owner",
            "limit": 1,
            "teamTypeDisplayName": "Agile Team",
            "teamType": "(group|team)"
        }
    }

Also supports signal overrides.

See Role Tag Parameters for details on the roleTagType and roleTagAttribute parameters.

Role Count

^parameter role, roleDisplayName, limit, teamType, teamDisplayname, roleTagType, roleTagAttribute

^title ${roleDisplayName} should work in no more than ${limit} {teamTypeDisplayName}

    {
        "type": "ROLE_COUNT",
        "args": {
            "role": "(.*product.*owner)",
            "roleDisplayName": "Product Owner",
            "min": 1,
            "max": 10,
            "teamTypeDisplayName": "Agile Team",
            "teamType": "(group|team)"
        }
    }

Also supports signal overrides.

See Role Tag Parameters for details on the roleTagType and roleTagAttribute parameters.

Ownership

^parameter maxTeamsPerMember, teamType

^title Should have 1 ${ownershipRoleDisplayName}.

consist of between 1 and ${limit} ${ownershipRoleDisplayName}.

Note: Ownership Role references Job Title (jobTitle) and the SPECIALIST Tag type (tagType) for a person. If either match, it will be seen as meeting the principle. (uses Regex - more examples below)

    {
        "type": "OWNERSHIP",
        "args": {
            "ownershipRoleDisplayName": "Product Owner",
            "limit": 1,
            "ownershipRole": "(.*product.*owner)"
        }
    }

Locality

^parameter maxLocations

^title Where teams are distributed it will be across no more than ${maxLocations} premises

      {
          "type": "LOCALITY",
          "args": {
              "maxLocations": 1
          }
      }

Field Match

^parameters field,metric,min,max,roleTagType,roleTagAttribute

^title Count of people that have matching values for a specifid field by number or by ratio

      {
        "type": "FIELD_MATCH",
        "args": {
          "field": "country",
          "min": 80,
          "max": 100,
          "metric": "ratio"
        }
      }

In the above, if there are any values for the country field where less than 80% of people have a matching value the principle evaluation fails.

      {
        "type": "FIELD_MATCH",
        "args": {
          "field": "country",
          "min": 8,
          "max": 10,
          "metric": "count"
        }
      }

In the above, if there are any values for the country field where less than 8 or more than 10 people have a matching value the principle evaluation fails.

Also supports signal overrides.

See Role Tag Parameters for details on the roleTagType and roleTagAttribute parameters.

Line Manager Count

^parameter maxManagers

^title Team should have no more than ${maxManagers} line managers.

      {
          "type": "LINE_MANAGER_COUNT",
          "args": {
              "maxManagers": 5
          }
      }

Role Conformity (TBD)

^parameter requiredTags,

^title Each team member should have a required set of tags.

Note: needs verifying by a dev (update this is only used by 1 customer so might not be something we use more broadly with a common set of needs(

      {
          "type": "ROLE_CONFORMITY",
          "args": {
              "requiredTags": [
                  "tag", "tag", "tag"
                ]
          }
      }

Role Diversity

^parameter requiredRoles,

^title Each team should have ${minCount}{Role}

Note: requiredRoles references Job Title (jobTitle) and the SPECIALIST Tag type (tagType) for a person. If either match, it will be seen as meeting the principle. (uses Regex - more examples below)

    {
        "type": "ROLE_DIVERSITY",
        "args": {
            "requiredRoles": [
                {
                    "role": "Product Owner",
                    "minCount": 1
                },
                {
                    "role": "Devops Engineer",
                    "minCount": 1
                },
                {
                    "role": "UX/Designer",
                    "minCount": 1
                },
                {
                    "role": "Senior Software Engineer",
                    "minCount": 1
                },
                {
                    "role": "Software Engineer",
                    "minCount": 3
                }
            ]
        }
    }

^parameter roleTagType,

Note: roleTagType references tag type for the requiredRoles. This defaults to SPECIALIST.

Total Role Diversity

^parameter requiredRoles

^title Team should be cross-functional and include the following capabilities:${requiredRoles}

    {
        "type": "TOTAL_ROLE_DIVERSITY",
        "args": {
            "requiredRoles": [
                {
                    "role": "Data Technician",
                    "minCount": 1
                },
                {
                    "role": "Field Technician",
                    "minCount": 1
                },
                {
                    "role": "Field Engineer",
                    "minCount": 3
                },
                {
                    "role": "Electrical Engineer",
                    "minCount": 3
                }
            ]
        }
    }

Same City Co-located (incomplete)

^parameter null

^title All members in the same city should work at the same address.

      {
        type: "SAME_CITY_COLOCATED",
        args: {}
      }

Child Team Count

^parameter maxTeams, minTeams, subGroupName

^title Should consist of no more than ${maxTeams} direct ${subGroupName}.

Should consist of at least ${minTeams} direct ${subGroupName}.

Should consist of between ${minTeams} and ${maxTeams} direct ${subGroupName}.

      {
          "type": "CHILD_TEAM_COUNT",
          "args": {
              "maxTeams": 15,
              "minTeams": 1
          }
      }

Direct Workforce Count

^parameter minCount, companyNames

^title Should consist of at least ${minCount} direct workforce members

      {
          "type": "DIRECT_WORKFORCE_COUNT",
          "args": { 
              "minCount": 4, 
              "companyNames": [
                  "Company Name"
                ]
          }
      }

Timezone Overlap

^parameter goodOverlap

^title Members geographically distributed should have at least <${goodOverlap} overlapped working hours.

TBC: need to confirm this is correct (code reference)

    { 
          "type": "TIMEZONE_OVERLAP",
          "args": {
                "goodOverlap": 3
          }
    }

Signal Overrides

By defaults the are three signals for principles they are:

• MET - green (success)

• NOT MET - red (danger)

• N/A - orange (warning)

These defaults can be overridden with the following config in those principles that support it:

"signals": [
  {
    "condition": "==0",
    "color": "success",
    "text": "<text to replace MET>"
  },
  {
    "condition": ">0",
    "color": "warning",
    "text": "<text to replace NOT MET>"
  },
  {
    "condition": "<0",
    "color": "danger",
    "text": "<text to replace NOT MET>"
  },
],

The arguments are interpreted as:

• condition - an arithmetic comparison - a comparison operator which is any of ==, !=, >, <, >=, <=followed by some number.

• color - a colour that indicates the status of the principle given the configured condition. Usually one of success, danger, warning

• text - the text that is to be presented in the principles tab. The defaults are MET, NOT MET, N/A.

Role Tag Parameters

For principles that support the roleTagType parameter this can be a string with a specific tag type (e.g. SPEICALIST) or it can be a list of tag types like:

"roleTagType": [
  "JOB_CAPABILITY_ARCHITECTURE",
  "SPECIALIST"
],

With this configuration the role parameter is compared with the tag value of the specified tag types.

To use the tag attribute values add the roleTagAttribute parameter. This parameter causes the principle to be evaluated against the tag attribute value rather than the tag value.

This parameter can also take an explicit string for a single attribute or it can take a list. The tag attribute name or ID can be used in this parameter. All of the following are valid roleTagAttribute settings:

Using one tag attribute name (or ID):

roleTagAttribute: "JA Role Code"

Using several tag attribute IDs (or names):

roleTagAttribute: [
  "abcdef",
  "jklmno"
]

Using Person Attributes

Parameter syntax

Many arguments use Regex. For example "role": "(.*product.*(owner|manager))" will match either product manager or product owner (or variations containing these words e.g. senior product manager, App product owner…etc). "role": "(.*agil.*coach)" will match agility coach, agile methodology coach..etc.

Bulk assigning principles to teams

You can use the Teams CSV import (Settings → Data Integrations → Create New - > Teams csv file upload

Use a csv file format as follows:

and a field map as follows:

Troubleshooting:

Can’t find a team a principle set in the drop down for a team?

It is likely you need to ensure a principle set is configured to have a suitableGroupType matching the team type for that team (as defined in Settings → Org Structure → Team Types)
E.g.

    {
        suitableGroupTypes:”squad” 
    }

Related articles