Leaders understand that collaboration between departments – business and engineering, engineering and QA, etc. is critical. Breakdowns between departments can be the cause of projects not finishing on time, information becoming siloed, and company culture declining. In my experience as a consultant and business owner, I’ve found that although individuals and teams must dial in to get their work done, the outcomes of larger initiatives are contingent upon the collaboration and communication of individuals, teams, and departments.

‍

Yet, enabling collaboration is easier said than done. Each team or department has a complete set of demands that require full-time energy in their functions. Because of this, healthy departments will create boundaries to save mental bandwidth for the specific problems they are incentivized to solve. This focus leads to big-picture value loss because teams will communicate and collaborate less with each other to keep their efforts focused on the work in front of them. However, there are some small shifts we can make in our communication to prevent these dysfunctions and maintain healthy collaboration. Much can be saved by thoughtfully considering how to make your colleague’s decision-making process easier.

‍

We should recognize that our teams only have so much mental energy available. When we interact with other departments, we can minimize the amount of effort required from them to achieve the desired outcome. The alternative is that we carelessly communicate in ways that require the simulation of variables, options, and requirements which often results in your colleague avoiding or isolating from you – “it takes too much energy to work with that person.”

‍

So what’s a perspective that can enable teams to maintain collaborative velocity when they aren’t incentivized to care about the same things? [insert celebratory music] Cue, computational kindness. What is it? It’s a process of considering and kindly minimizing the mental effort required from others to complete your calls to action.

‍

Brian Christian in his book, Algorithms To Live By, defines this communication issue in the following way:

“Seemingly innocuous language like 'Oh, I'm flexible' or 'What do you want to do tonight?' has a dark computational underbelly that should make you think twice. It has the veneer of kindness about it, but it does two deeply alarming things. First, it passes the cognitive buck: 'Here's a problem, you handle it.' Second, by not stating your preferences, it invites others to simulate or imagine them. And as we have seen, the simulation of the minds of others is one of the biggest computational challenges a mind (or machine) can ever face.”

‍

So here’s your classic example. Which question is computationally more difficult?

• “Where do you want to eat for lunch?”

                      OR

• “Would you rather eat Buffalo Wild Wings or Chipotle? I can do an hour between 11:30 AM and 1:30 PM.”

‍

The first question is missing essential details that could save your colleague's brain power. Are there any time constraints for eating out for lunch? Does the person asking have any dietary preferences or requirements? Framing the question in this way requires the other person to do the “work” of simulating all of these considerations. These are the types of questions that I would qualify to be energy-expensive.

‍

The second question eliminates many of the simulations as well as defines constraints so the person being asked has relatively little work to do to collaborate and get to the next step, which in this case, is getting together for lunch.

So how does this work regarding collaborating with teams and across departments? Glad you asked! Here are a few examples of what this looks like in practice and why it matters.

‍

1. It’s easier for a person to tell you what they do NOT like versus what they do like.

‍

If you apply this to your business or engineering counterpart, you can lead with communication that gets the NOT THIS portion out of the way right off the bat. This can look like providing a list of potential solutions early on in scoping conversations or providing general user story examples to identify what your counterpart doesn’t want.

‍

2. Minimize simulation.

‍

Instead of asking broad questions like, “where should we get this data from?”, start by identifying the places that data can be retrieved from and present your discoveries. This would look something like, “I did some research and this data is held in X database and from Y API. Do you have a preference if it should come from either of these places or elsewhere?”.

‍

3. Set up “visuals” or “alerts” that protect from dividing attention.

‍

ARTEM KAZNATCHEEV wrote about this on the egtheory blog. He explains that taking similar concepts surrounding attention and baking them into your processes for collaboration is quite valuable. His example is the benefit of adding signage for people waiting at a bus stop. This signage gives you a read out of when the next bus arrives. This gives a person the ability to have undivided attention back. Without the sign, a person has to keep watching for the bus, keep their attention on their tasks at hand, as well as continually gauge whether it’s the right time to make new plans.

‍

This is true for our teams. It requires much more attention to write code or define specific business outcomes than it does to wait for a bus. You can save yourself and people you are working with from having to hold attention by setting up an alert. The alert is to ensure you circle back on things that are currently blocked or in progress. By doing this, you and your colleagues no longer need to divide attention while you focus on your immediate tasks.

‍

Conclusion

In my experience working in and across teams, I’ve found that keeping computational kindness top of mind helps build rapport, trust, and an environment where we can do great work together. This has helped me get projects across the finish line, fostered better work relationships, and helped me better understand the incentives and priorities of adjacent departments. I hope my sharing helps you improve your own collaborations and interactions. And remember – be kind… computationally.

‍