Personal context, the foundation of collaboration
How often have you shared an opinion or thought with someone you don’t know, but they’ve expressed an entirely different one? How did that turn out?
A person is a collection of experiences, knowledge, and their background. Every person. Two people who attended the same school may have had entirely different experiences, based on their family life, classes they took, or friend groups they had. As a person grows, their experiences diverge and become even more diverse and different. Jobs, hobbies, relationships, they all contribute to a person’s individualism.
In an initial exchange, the information each person conveys is only surface deep. It might not even be their true opinions. It might even continue in future exchanges, as the people involved hide their true thoughts, or why they have those thoughts.
In most cases, it doesn’t matter if a person shields their true opinions from people they’ve just met. In most countries, the appropriate response to a stranger saying “Hi, how are you?” isn’t “I’m having a really rough day, my cat is sick and I’ve lost my favourite socks”, it’s “I’m good thanks, how are you?”.
It’s normal, until you’ve discovered some common ground. Being open, honest, and transparent comes with trust and safety. If this doesn’t happen, the interactions will remain surface-deep.
When two parties are expected to interact and work together, then there should be a level of trust and safety. Both parties in the conversation should be on the same level for discussions to be fruitful. It’s not about saying how bad or good your day is. It’s about being honest during discussing work load, disagreements, or expectations.
Teams don’t need to agree on every topic, and shouldn’t. But collectively, they should agree and understand how they work together. The needs of the team outweigh the wants of the individual. That’s not to say that individuals should sacrifice their happiness in favour of the team. But there should be pragmatism. Some of the best words I’ve learnt to use are “I’m happy to be wrong”.
Many of my best collaborators are those who will challenge me, and help make things better.
There are many layers of context to set in a company.
The C-level leaders clarify what direction to aim in, and why
The team leads set the execution direction, and prioritisation
The managers establish personal context
There’s many more levels to this, and different organisations have different setups. But you get the idea: leadership, of all levels, are there to help define the context of the company, and the team. That's a whole other topic for another post.
This post, we’ll focus on the interpersonal context that teammates share when it comes to collaborating together.
A visualisation of honesty, and disagreements
If there’s a lack of honesty, then assumptions are made. Without honest feedback, a party might continue along a path that the other parties don’t actually agree with. There’s a chance that the other parties will undermine the initiative, or not back it enough.
I see the openness something like this:
📕If there’s hidden thoughts:
🤝And you agree, it could lead to collective happiness. But it could also be passive.
🤨But you disagree, then it can lead to frustration, or devalue the interaction.
📖 If there’s openness:
🤝And you agree, then collectively the parties are happy or unbothered.
🤨But you disagree, it could be bad, it could be good. We’ll look at that next.
I like to picture honesty as something like this:
🤨If there’s disagreement and it’s honest:
🥗And conducted in a healthy way, then that’s a chance for growth and progress. Growth in this case could be personal growth, but it could also be collective growth: the team, the codebase, the product.
🐛But conducted in an unhealthy way, then it leads to the parties involved being frustrated, or becoming blocked. It’s frustrating when a disagreement doesn’t resolve in a healthy way, or a way that progresses.
🤝 If there’s agreement, and it’s honest:
🥗And conducted in a healthy way, then things progress without too much noise. It usually feels good to hear people agree with you, which is why I’ve labelled it “happiness”.
🐛But conducted in an unhealthy way, things will still progress, but it could turn sour. “Treading on eggshells” is the English expression for this - the parties walk softly on top of eggs, in fear of the shell breaking.
Let’s take a look an example where disagreement could have been good, but wasn’t, due to hidden context of the parties involved.
A mostly accurate example
It’s a bit of a misnomer to think “these two people both know React, therefore they must be able to build a frontend together”1. There's intricacies to their backgrounds: one might've come from Angular, the other might prefer class components. If they're unable to communicate on which direction they'd like to go in, then silos form.
“Can you change the account page to say ‘Hello surname’ instead of ‘Hello name’?”
“Sorry, that's the other person's code, we should wait for them.”.
An exaggerated example, but I've seen similar things pop up many times.
Many years ago, I worked with a team that had a tech lead that did not work on the codebase, but led the team that did. It's somewhat common to have this set up, so that’s not so unusual. The technical decisions were made by the lead. My role was to consult, and to implement the frontend. Their lead didn't have many opinions when it came to frontend, so any framework we wanted could be used. The backend was a small yet slow Java backend, slowed mainly by the fact the server actually called out to another, non-Java process to do most of the work. To give you an idea: it used 1.3GB of RAM, served only 6 fairly basic endpoints, and all the actual logic was handled by another process.
We had many discussions about the architecture, and how it could be simplified. But the technical decision came down to “we must use Java and Spring”, without further details on why these technologies were crucial. I was lacking the context. So I wrote a matching server in Python for development usage, and did some benchmarking - the Python was faster in all cases, fewer lines of code, and just as secure. The external process had better interop support in Python, so the Python server used less than 20MB of RAM.
The lead was missing the context that I faced: the server was slow and difficult to debug. The RAM usage made it hard to work with on my development machine. Neither context managed to fully communicate to the other, and so the server continued in Java, slowing development down to the point where I chose to stop working on the project.
In hindsight, writing an alternative in Python probably wasn’t the right way of convincing the lead that the server was too complicated for development purpose. Instead, we should’ve talked, disagreed, and debated. I should’ve pushed more to understand why the lead felt like Spring was the right choice. There could’ve been many valid reasons that convinced me. But without that context, I didn’t understand the need, and the lead didn’t understand why I was frustrated.
We should’ve focused on establishing honest yet frank communication, not the code. We did spend a lot of time getting to know each other, but not enough time having productive, difficult, debates.
How to establish a team’s individual contexts
These scenarios happen all the time. I saw it happen earlier today, I probably saw it yesterday, and I definitely saw it last week. Whenever two parties discuss a topic without openly sharing their thoughts and experiences, and debating them, it happens.
Interpersonal relationships between team members is the foundation for a team working together. One of the best things that managers and leads can do for their team is to make sure they know each other, and how to interact.
So how can we share our contexts, without sitting down and reading someone’s diary and CV the first time you meet them?
There’s two branches I’d recommend: establishing an environment where you can openly share your thoughts and opinions, and providing an introduction to yourself covering topics good for collaboration.
To establish the environment:
☕ Spend time getting to know everyone, as soon as possible.
The better you know each other, the easier it is to disagree.
🗓️ Continue to invest time in communication as the collaboration continues.
One meeting at the start isn’t enough for a long term collaboration, it needs to be repeated.
💬 Find a topic you disagree about, and debate it.
If a technical discussion gets difficult, resolve it in a healthy way.
Tech leads: this is usually where you come in.
If other interactions become bad, figure out how to proceed.
Managers: this is usually where you come in.
📑 Establish “ways of working” or “team contract”, defining the way your team works.
Consider a work playbook, describing the rituals a team is expected to follow. It’s handy if this is accessible by people outside of your team!
To introduce yourself:
📖 Write a “manual to me” describing your needs, dislikes, skills, and background for work life.
What might be a happy “:)” to one person, might be a passive aggressive “:)” to another2.
👋 Talk to others you’ll be collaborating with.
When you meet someone that you're going to collaborate with, I suggest asking questions that give you further insight into their experiences and opinions. If they say something you disagree with, ask questions to figure out why they have that opinion. Hold back on strongly disagreeing until you understand their angle, and then introduce your own opinion. Voice disagreements, but do so in a productive way.
As a facilitator, some fun ways I like to understand a group’s opinion and promote discussion:
🤔 Play the devil’s advocate: make a case for the counter point, even if you actually agree.
🙋Ask follow up questions to identify why someone has an opinion. It’s a bit of a variation on 5 whys, where you invite someone to express why they have a particular opinion.
🪢Act as a “joker”, and intentionally introduce some chaos. Throw out several different opinions on one topic, and then see how the group discusses.
Conversations often need multiple threads in order to land on a good conclusion, which often might look like chaos. Learning how to navigate through chaos can lead to productive solutions.
If all parties have an understanding of each other's contexts, it'll be a far more interesting conversation. You might even change your opinion.
Everyday when you're walking down the street
And everybody that you meet
Has an original point of view
And I say HEY! (HEY!)
What a wonderful kind of day.
If we can learn to work and play
And get along with each other
—
Ziggy Marley, The Arthur Theme Song
I’d love to hear anyone’s stories or counter-opinions to this. It’s how we learn, and grow!
Low budget movie idea: “The Lobster”, but about developers trying to build something together.
I had experience this myself, and now try to match the emoji usage of who I’m talking to.