Clarify when/how adding custom fields to roles is allowed

[brianjrobertson]

A few organizations/circles have wanted to add custom fields to the definition of a Role/Circle or a Policy - e.g. adding a "Customer" field on a role. Perhaps a field like this would initially be used just to hold contextually-relevant information (e.g. which other role is the customer of the one in question), but it could also be referenced by other governance to make that field more meaningful (e.g. a policy requiring getting input from the designated Customer role before finishing a project or spending resources or whatever).

This brings up a couple of questions:

1) Should the constitution be flexible enough to not prevent a circle from defining a policy requiring all governance to include some custom field (e.g. "no one may create a role without defining its Customer"), or should it be unconstitutional to limit governance proposals with a requirement like this?

2) If your answer was that the constitution shouldn't prevent it, should it go further by having a built-in mechanism to more explicitly allow/support a circle adding custom fields to its governance entities (roles & policies)?

Of course, I'd especially love any real-world examples to support any answers you might offer...

[tensiondriven]

Clarifying question: You give the example of a custom field on a Role called "Customer", but don't give an example of the name of a Role that might have this custom field. Can you give an example of a Role name that wants to have a custom field called Customer so we can better understand the motivation for the feature?

[brianjrobertson]

Could be any role, to clarify which other role/party that role should treat as its key “customer” (internal or external). So, our Training Operations role might have our Trainer role as its Customer, and our Trainer role might in turn have our trainees as its Customer. FWIW, I’m not even sure this example of adding a Customer field makes sense or would be worthwhile for any given organization - it was just one example of something that one of our clients thought would be useful for them to experiment with.

On Jan 20, 2016, at 2:46 PM, Jonathan Yankovich notifications@github.com wrote:

Clarifying question: You give the example of a custom field on a Role called "Customer", but don't give an example of the name of a Role that might have this custom field. Can you give an example of a Role name that wants to have a custom field called Customer so we can better understand the motivation for the feature?

— Reply to this email directly or view it on GitHub https://github.com/holacracyone/Holacracy-Constitution/issues/66#issuecomment-173337970.

[tylerdanke]

I added a "standard operating objective" field when I created our initial roles when I started Holacracy in October. Each role is either in the Customer Paradise, Vendor Harmony, team Happiness, Marketing Melody, Financial Peace, or Product Nirvana standard operating objective. For example Customer service representative role is assigned to the customer Paradise standard operating objective.

I kind of wish that I had done it as two fields: stakeholder group and plan. For example Customer service representative would be stakeholder group: Customers and the plan would be Operations. My company has only one circle of 8 core members,so it doesn't make sense for us to have 3 or 6 circles but at least we have a field of standard operating objectives assigned to the roles Accountant and Accounts Payable and Auditor roles so that we can refer to those 4 roles easily.

[tylerdanke]

The Constitution should not prevent a circle from defining a policy requiring all governance to include some custom field. The Constitution should go further by having a built-in mechanism to more explicitly allow/support a circle adding custom fields to its governance entities.

[dienkwik]

I like the idea of allowing custom fields to be added as outputs of governance for roles. We have been thinking of specifically doing this via a policy to allow adding fields such as "key customers", "performance measurement", and/or "badges required" to further describe the roles.

"Key Customers" will be used for the purpose of performance feedback, i,e. the key customers are the ones that is in the best positom to give feedback to a role, and so the role needs to know which roles are its key customers.

"Performance Measurement" is similar to in Sociocracy, where if I'm not mistaken, for every role created. they also define what are their KPIs, or how to measure its performance.

"Badges required" is to clarify what qualifications are needed for a partner to fill a role.

Some of these fields can be mandatory and some can be optional, depending on the policy created for these custom fields.

Also, any circle should be able define this policy to add custom field only for its own circle and the subcircles below it, thus allowing different circles to have different custom fields according to their needs. Ofcourse, if you need all circles to add this custom field, then the broadest circle can define it there.

I don't think an extra built in mechanism is needed other than just stating that this can only be done through a policy.

[tylerdanke]

Another example that I would like to add is a field like "Requirements or Prerequisites to fill this role" for example... Ability to lift 70 pounds or type 60 words per minute.

Tyler Danke Tyler@purelypoultry.com 920-359-0554 https://www.purelypoultry.com/ On Jan 30, 2016 5:40 PM, "dienkwik" notifications@github.com wrote:

I like the idea of allowing custom fields to be added as outputs of governance for roles. We have been thinking of specifically doing this via a policy to allow adding fields such as "key customers", "performance measurement", and/or "badges required" to further describe the roles.

"Key Customers" will be used for the purpose of performance feedback, i,e. the key customers are the ones that is in the best positom to give feedback to a role, and so the role needs to know which roles are its key customers.

"Performance Measurement" is similar to in Sociocracy, where if I'm not mistaken, for every role created. they also define what are their KPIs, or how to measure its performance.

"Badges required" is to clarify what qualifications are needed for a partner to fill a role.

Some of these fields can be mandatory and some can be optional, depending on the policy created for these custom fields.

Also, any circle should be able define this policy to add custom field only for its own circle and the subcircles below it, thus allowing different circles to have different custom fields according to their needs. Ofcourse, if you need all circles to add this custom field, then the broadest circle can define it there.

I don't think an extra built in mechanism is needed other than just stating that this can only be done through a policy.

— Reply to this email directly or view it on GitHub https://github.com/holacracyone/Holacracy-Constitution/issues/66#issuecomment-177338799 .

[brianjrobertson]

It would be a very simple add to allow requiring additional fields on a Role via a Policy, though I find that I'm hesitating to add it, out of concern that it could easily be misused and complicate governance. So I'm thinking about dropping this until absolutely proven it's needed (which means it would be disallowed, but you could still add whatever fields you want to a Role, just not as part of the role definition and thus an output of governance). Anyone else want to pitch to go with this concern/approach, or pitch to ignore the concern and allow it anyway?

[bernardmariechiquet]

I'd pitch to ignore that one as it would complicate governance and increase learning curve and I don't see into this thread any urgency/concrete replicated cases. Would love GlassFrog offering some features to allow that.

[jennyslack]

I would prioritize simplicity and agree with Bernard Marie that complicating governance and increasing the learning curve holds significant weight. I think especially with this release of the constitution and where Holacracy is in the growth curve, maximizing usability has to be a priority.

I would also say that for those who find it valuable to have custom fields perhaps they could work on a clear app that would introduce that, like Brian describes, as a part of the role but not the governance defined role definition. For our organization the tags in glassfrog largely serve this purpose and I feel no tension about it being not the output of governance.

[brianjrobertson]

Thanks! Dropping this...