The fundamental behavioral interactions on teams
The fundamental interactions when you and another person are working together on a team.
A recap of the behaviors
- 🧶 - a behavior
- 🧶⚙️ - behavior and logic combined - we call this principled behavior
- 🏀 - a behavior that the other person has which is different from our own
Interactions table
The basic interactions for people on teams are as follows:
| Your behavior | Other persons behavior | Behaviour name | Primary interaction |
|---|---|---|---|
| 🧶⚙️ | 🧶⚙️ | matching principled | Alignment |
| 🧶 | 🧶 | matching automatic | Alignment |
| 🧶⚙️ | 🏀⚙️ | opposing principled | Learning |
| 🧶⚙️ | 🏀 | principled vs opposing automatic | Persuasion |
| 🧶 | 🏀 | automatic vs opposing automatic | Conflict |
Primary interactions
The most common interactions caused by the behaviors
Alignment
🧶⚙️ | 🧶⚙️ & 🧶 | 🧶 - matching principled & matching automatic
These two people share the same behaviors. If they know the logic behind it, they can talk about it if they so wish. If they don't, it's also not a problem because they are already aligned. The ideal and leads to the most productive teams.
Example
A basic example would be a variable assignment. Everyone on the team will know how to assign a variable and have that as an automatic behavior and won't even think about its logic.
A more complex example would be a single source of truth (https://principles.dev/p/one-single-source-of-truth/). People might know this principle and follow it, or have learned, through trial and error, to automatically structure their code this way.
Learning
🧶⚙️ | 🏀⚙️ - opposing principled
The behaviors are different, but both can explain why they believe their point of view. The individuals will eventually reach a solution. Usually, one or both learn something. It may lead to the discovery of new behaviors (i.e., underlying principles) - while understanding pros and cons - or aligning with the others' way of thinking.
Example
Static vs. dynamic typing. Both might have logical reasons for choosing one over the other and can explain those reasons. One prefers static typing for better documentation and better operation on teams due to higher rigidity. The other will choose dynamic typing because it's faster to get started or work on a problem that requires highly dynamic data. If they are working on a prototype, they may agree that it makes sense to use dynamic typing. Whereas if they have bigger teams and a codebase that will exist for longer, they may decide to go with static typing. Either way, both parties understand the logic, and inevitably at least one person will learn something from that interaction.
Persuasion
🧶⚙️ | 🏀 - principled vs opposing automatic
The person who knows their behavior and logic has an advantage over the person who has the behavior with no logic. They are more likely to be able to convince the other to adopt their behaviors or encourage the other person to find the logic behind their behavior to discuss their points of view more clearly.
Example
Automatically enforced coding conventions (https://principles.dev/p/use-consistent-coding-conventions-automatically-enforced/) would be a logical automatic behavior.
Automatic enforcement means using tools such as gofmt, eslint and pylint. The person who has the logical reason will prevail against the person who doesn't want to use one of those tools and doesn't have a logical explanation. The logical behavior can convince them of the merit of that choice versus their non-logical feeling against not using it.
Conflict
🧶 | 🏀 - automatic vs opposing automatic
Conflict is caused when two opposing automatic behaviors come into contact. Both parties don't understand the logic behind the conflict. It is the realm of feeling. That means whoever "wins" the conflict will leave the other person feeling like they have lost.
The conflict manifests itself in many ways, but the overall outcome is doing things sub-optimally. Conflict doesn't necessarily mean outward conflict, the person may choose to accept a behavior enforced upon them, but the conflict is turned inwards, towards themselves. It goes against what they know and creates negative feelings which lower their energy. It can lead to burnout if too many opposing behaviors are enforced upon them. For them, they are working in an environment which isn't rational.
Example
Terse code vs. non-terse code. i.e., Single line of code doing many things vs lots of lines doing one thing per line.
If a team enforced the use of terse code, that would be negative to the people on the team who don't like it.
The logic behind terse code may be: It looks cleaner, they also might be a specialist in that language, so know all the features in-depth. They may like to show they can use advanced language features because they see it as a sign of intelligence.
The logic behind non-terse code may be: They may want the code to be more readable and require less cognitive load when they come back to it. They may be more generalist working over multiple programming languages. They may want to make it easier for less experienced members of the team to understand their code. They may believe code should be about reading, not writing. The principle behind it could be: "Code should optimized for reading, not writing."
But if either side cannot express the above logic. It gets stuck in the world of feeling. Conflict will ensue, whether expressed externally - to the team - or internally - to yourself.
Additional interactions when behaviors don't exist
- ? - a behavior that doesn't yet exist
| Your behavior | Other persons behavior | Behaviour name | Primary interaction |
|---|---|---|---|
| 🧶⚙️ | ? | principled vs no behaviour | Teaching |
| 🧶 | ? | automatic vs no behaviour | Adaptation |
| ? | ? | no behaviour | Discovery |
Teaching
🧶⚙️ | ? - principled vs no behavior
The other person can explain the behavior and the why, so they can teach the other person and add it to their knowledge.
Adaptation
🧶 | ? - automatic vs no behavior
When one of the parties hasn't learned behavior for a particular task, and the other person has but cannot explain their logic, the person usually has to adapt to the behavior. They don't know if it's good or bad. Their behaviors can be created without logic, and the rationale may become "I've always done it this way". Or "this is good because X says it's good." This is a sub-optimal way of Learning that can lead to bad habits and behavior you don't understand.
It's also often the primary mode of being when you pick up a new framework or a new code base, as most of the time, frameworks and code bases don't come with in-depth principles for you to understand.
Discovery
? | ? - no behaviour
Neither of you knows the behavior, so you have to figure it out.