In the last article, we already noted that all teams per category can have certain things in common. These are reflected in a common structure, which creates more order within the categories.
However, there is another aspect that distinguishes the teams per category: The so-called “self-service”.
Self-Service describes the possibility that every employee of your company is allowed to create his own teams. On the one hand, this is helpful, because many employees feel blocked in their work if they have to wait too long for a team. But on the other hand, this can also create many team duplicates in a short time, or masses of teams in which people no longer work together at all.
Therefore, there are now two opinions among consultants. Some claim that self-service should be activated (e.g. the team of ShareGate – USA), others claim that self-service is a governance danger and should be the first thing a company should deactivate (often German consulting firms).
As so often in life the truth lies somewhere in between.
And this is where the work we have done so far with categorization helps us a lot.
For example, let’s take all the teams from the “Department” category.
It probably won’t happen often in your company that new departments are created or dissolved. Departments are long-lived structures and can exist for decades.
So it would not be very advisable if every employee would be able to create new department teams. This administrative task can be safely left to one or two people per site.
It is probably different with your customer projects.
A customer project is completed after a few weeks or months and can then be closed. However, there will always be new customer projects per year (at least we hope so for you).
However, customer projects should not be able to be created by everyone, but only by the sales department – or maybe even indirectly through an ERP system.
So the self-service for “customer project teams” is obviously different from the self-service of “department teams”:
In the same way, there may be very “open” categories where every employee should be able to create new teams. Thus, for example, one could allow everyone to plan new events and also create a corresponding team.
Team-Approvals
Team Approvals are an interesting intermediate solution. Here you can define a set of employees in a category who can approve new teams.
For example, it would be possible to define the group “Marketing” as approver for new event planning teams.
If an employee creates a new team “Summer party 2022”, a marketing employee would first have to approve this team and only then would the team actually be created.
Team Visibility
Not all teams in all categories should be visible to all employees. For example, it could be that there is a category “Management” in which the management would like to collaborate alone.
It would therefore be conceivable to “hide” all teams in this category, so that the “normal employee” does not even see such teams.
Summary
The topic of self-service seems to be somewhat more extensive than one might assume for the time being.
So the same questions arise again and again per category:
- Should all employees be able to create new teams in this category or only a subset of people?
- Should there be a group of “approvers” per category, which is able to approve corresponding teams?
- Should all employees be able to see the teams in a category or only a subset of people?
A final note
Even though step 3 only deals with creating/viewing teams, the topic of permissions goes much deeper. Within certain team categories, it can therefore make sense to deal with the topic in more detail. However, because it becomes very individual per company here, we intentionally leave the topic out of the four-step plan, which is intended to be as general as possible. Please also read the article on the subject of permissions.
Proceed to the final step.
