Defaults and Standards
Have you ever observed a situation in which teams spend hours and hours coming up with their unique ways of working? They discuss thoroughly how they want to run their daily standup, if they want to work in sprints or not (and if yes: how long they should be), who should facilitate their retros etc.
Especially for newly (re-)formed teams this is often not the best use of their time. Firstly, some of these things might not really matter. And secondly, the team will know better what they really need, after they have worked together for a while.¹
Instead of every team coming up with their own ways of working from scratch, I often find it a better approach to use organization-wide defaults (I first read about defaults in the book Brave New Work by Aaron Dignan).
Defaults might look similar to standards, but they are in fact quite different.
Standards
Standards specify how things are done in an organization, and they demand compliance. If someone does not comply with a standard, this person often will face sanctions. For instance, internal IT might set a specific tool as the standard for issue tracking and ask everyone to use this tool and this tool only. If they find out that a team uses another tool, they might escalate this violation of company standards to the big boss who will then have a pep talk with this team to get them back on track. Maybe this team has a good reason to use another tool, but that doesn’t really matter much. They might now decide to use the tool which is of very little use to them, which is of course quite frustrating. Or they might decide to continue using the useful too, but now they have to do it secretly, constantly fearing they someone finds out again.
Defaults
Defaults on the other hand are recommendations for how to do things, they suggest a certain baseline. If you already have ten product teams in your org and they all are happy with how they run their daily standups and biweekly retros, what are the chances that the next product team will need something completely different? In this scenario we could provide a lightweight “playbook” for how to bootstrap new product teams, containing defaults for team cadences, roles, responsibilities, tools to use etc. Most people will happily use these defaults as a baseline to get started quickly. After a couple of weeks or months (1) they might decide to tweak some of the ways of working or experiment with new things, and this is of course totally fine. At this point the team will have formed shared hypotheses for what to improve and why. So what defaults really do is to reduce cognitive load from teams by telling them: “Here is a set of things that have proven useful in our organization. We highly recommend you use them as a starting point for your team, as well. But if you have a good reason not to, you are also welcome to deviate from these defaults and come up with your own ways of working. Please let the rest of the org know how it went and what you learned.
A default is a starting point rather than a law.
Case Study
In one company I worked at, every team was supposed to self-organize how they got the work done. They had a lot of freedom regarding their processes, tools, working hours, ways of working etc. And their self-organization was also bounded by constraints. These constraints were printed on posters and they were also shown to new joiners during onboarding. Many of these constraints were followed by defaults for how to bring these constraints to life. Sounds abstract? Here are two examples:
While the teams had to continuously improve and provide transparency (which is a reasonable expectation, if you ask me), they did not have to use retrospectives or Kanban boards as their methods.
This list of constraints was not only useful for having fruitful conversations with existing teams (“what have you tried to continuously improve?”). It also turned out to be a really valuable tool for bootstrapping new teams. During kickoff workshops (there’s a separate post on the topic), we would go through this list and for each item ask the team: “How would you like to make sure you are following these constraints? Do you think the defaults would work for you, or would you like to try something else?”
This saved us a lot of time and helped the teams focus on more important topics for the kickoff.
Takeaways
Defaults can be a useful concept to reduce cognitive load for teams and individuals whilst still giving them autonomy to come up with their own ways of working. Unlike standards, defaults are suggestions for how to do things. Folks are encouraged to start with these default, but they are welcome to deviate, if they believe this will benefit them.
__________
¹ Connie J. G. Gersick suggests that the temporal midpoint of a project or the completion of a significant task is a good time for a team to reflect on and change their ways of working. At other times they might not be open to this topic.
Strukturen moderner Unternehmen
Am 18./19.12.2024 gebe ich mit meinem Bruder Stefan eine Schulung in Hamburg. Dort werden wir mit vielen Praxisbeispielen erörtern, wie man Unternehmen auf Effektivität, Flow und Innovation ausrichten kann.