Learning from the neuroscience of trust

Trust is the foundation of the human relationship and the foundation of an effective team. I recently shared how our behavior will create or destroy trust in the article The Evolution of Trust, and more about trust as the foundation of a team in the article The Five Dysfunction of a Team.

Paul J. Zak, the author of Trust Factor, shares in The Neuroscience of Trust the 8 management behaviors that will foster trust.

We could use the 8 behaviors as discussion points with teams to improve our way of working. The question could be, How are we doing on:

  1. Recognize excellence: personal public recognition from peers that occurs immediately after the fact, tangible and unexpected has the largest effect on trust.
  2. Induce “challenge stress”: stretch goal, but a still achievable goal, assigned to a team will intensify focus and strengthen the social connection.
  3. Give people discretion in how they do their work: autonomy and self-organization, is another important contributor, being trusted creates trust.
  4. Enable job crafting: trusting people to choose what they will work will ensure focus and motivation. The author gives the example of Valve, the gaming software company, I recommend their employee handbook to have an idea of how they work, and inspire the conversation with your teams.
  5. Share information broadly: uncertainty and stress undermine teamwork, openness, transparency and daily synchronization are the proposed antidotes.
  6. Intentionally build relationships: encourage people to care for each other will make them happier and more productive.
  7. Facilitate whole-person growth: meet frequently and give constant feedback on personal and professional growth.
  8. Show vulnerability: asking for help, and acknowledging what we don’t know, help to build credibility.

Could this discussion be the Retrospective on Trust for your team?

Hierarchy and Decision Making

Erin Meyer covers how cultural differences in leadership styles create unexpected misunderstandings [Being the Boss in Brussels, Boston, and Beijing of the last issue of Harvard Business Review].

Looking at how people behave towards hierarchy is not enough to understand what kind of leadership style they will expect. A second dimension needs to be taken into account: attitude towards decision making.

Coming from France, I was making a simplistic association of hierarchy with the top-down decision making and was puzzled by the Japanese who were clearly experts in getting to a consensus while they were still hierarchical.

Of course, generalizing the expected behavior for an entire country is not fine grained enough, and you could expect different behavior from people of those countries.

The key is to understand that hierarchy and decision making are 2 different dimensions to discuss when you are building the team agreement on how you work. And when you are working with teams that are made with team members coming from all over the world, this is key to the success of the team.

For example, my understanding of Self-organization is egalitarian and consensual, and it’s for me the opposite of the top-down and hierarchical approach. The managers and team members, involved in a transformation towards a self-organization model, could struggle with defining their roles, especially if they are more comfortable in the 3 other quadrants.

Do you have your team agreements written down?


The Evolution of Trust

When forming a team, or starting to work with a team, I usually start with the foundation of a team: Trust.

I even used several times, the book from Patrick Lencioni: The Five Dysfunction of a Team, obviously because the “Absence of Trust” is the base of the pyramid.

I remember playing 2 times, with large teams, a game based on the game theory, and a variant of the prisoner’s dilemma. The effects with one of the team were really great, for the one, where one of the participants betrayed not only the other team but also his own team, the results were not so good, for him and for his relationship with others in the larger team.

So I am always struggling with the idea of bringing that game to build trust, because we could have someone in the group that will betray the others, and after that, it is difficult to deal with it. One of the participants told me one time: “at least, now, we all know”.

The idea of the article has been triggered by the brilliant work from Nicky Case: The Evolution of Trust.

The recommendation (The ask?) is for you to play with it, and to get other people to play with it.

This could help you and others to better grasp how we build or destroy trust.

Ready to play?

It’s here: http://ncase.me/trust/

Team Identity

The sense of belonging is an important experience to have. Belonging means that we are accepted as part of, as a member of the group, the team, the company.

We want to be part of a team because what defines the team identity is appealing to us. The team is defined by its vision and its working agreements.

When you are building software the open source way, you can identify 3 main categories of team identity:

  1. Upstream project
  2. Downstream product
  3. Jobs to be done

1- Upstream project

The team members belong first to the upstream project. They will tend to prioritize what they think is the best for the upstream project. They will be progressively disconnected from the people that are using the technology they build. They could even miss new needs and be surprised that people switch to another technology that is not so different/better/other qualifiers…

2- Downstream product

The team members belong first to the product they build. They will tend to prioritize what they think is the best for the product. They will tend to forget that building the open source way is a great way to understand why people want to use the technology by confronting your point of view and requirements with those of the other members of the community. The extreme is that they will end up being alone, and disrupted by another product.

3- Jobs to be done

The Jobs to be done theory has been described by Christensen and his colleagues. I wrote an article about one of his book: How to measure our life and I will probably write another one about Competing Against Luck.

In short, the Jobs to be done theory explains why people are making choices, hiring or firing a product or service, by focusing on the understanding of the jobs, the problem they are trying to solve.

The teams that identify themselves to the jobs to be done are stronger because they can work on technologies in the open, curate technologies that they need, invest in new technologies that could replace their current core technologies, without losing their identity. They can envision their solution as a sole product, or integrated into other products knowing that the most important thing is the jobs to be done. They can partner with other knowing precisely what they are partnering on without feeling that they could lose/win something in the partnership. They can focus on their users and solve a specific problem, a specific “jobs to be done” without the temptation to expand the scope of what they are doing.

I guess that the jobs to be done should be the first thing you want a team to agree upon.

Thoughts? Please comment, tweet, email…




The header picture is from Ryan McGuire.

Let us code!

I started this article a long time ago. And that’s a comment from a person I work with that triggered the sense of urgency to contribute to solving this problem. He said:

Stop interrupting us! Let us code!

I became sensitive to interruptions when I discovered the Pomodoro method, subject that I covered in this article.

I experimented that, when I was able to focus on one thing, I was extremely efficient. Though, I tried to influence people in teams I worked with to preserve periods of time without interruption.

People easily identify others as interruption sources. It is usually something easy to cover with a team to find agreements to stop the interruption flows and halt the downside of them.

It’s harder to admit that we are our source of disruption. We start something, get caught by notification, our mind wanders and takes us somewhere else… We need a strong commitment to resist to the multiple temptations to quit what we are doing for something else.

The problems became major with a distributed team.

With colocated teams, I experimented two strategies:

  • The first one is to adopt a sign on the desk meaning that the person wishes not to be interrupted (a funny puppet for example)
  • The second is to synchronize the team on the same schedule: 50 minutes of work without interruption, 10 minutes break, 15 minutes for interruptions, and so on, with a bigger break for lunch.

Synchronization is the most efficient strategy, but it’s also the most demanding one for team members.

With a distributed team, the connection flows through electronic communication means. You can observe some tacit agreement that you need to answer fast to solicitations by email, and more rapid to solicitations on chat rooms (IRC, jabber, slack or others).

If you agree with that, you can spend your whole day jumping from one subject to another without actually accomplish something.

LarryKim-MultitaskingThe illustration on the right is coming from Larry Kim’s article multitasking is killing your brain, and it explains quite well the situation.

Our overall satisfaction will suffer from those constant context switch. Furthermore, each time we will try to go back to a task, it’s very likely that we will need a lot of time to regain the level of understanding of the problem we had when we left this work.

MikeCohn-ContextSwitchingIn his book Succeeding With Agile, Mike Cohn quotes the study from Kim Clark and Steven Wheelwright on the impact of multitasking on productivity that as shown in the graphic above.

In an organization where managers distribute the work and where the managers convey the pressure of instant response, the time wasted by permanent asks will paralyze the whole organization. This explains why some small teams of 10 can achieve more than teams of 300 letting bigger organizations questioning themselves.

The phenomenon will be less important in an organization where the system distributes the work. An organization in which each team member knows what he/she needs to take after a completed task.


Funny synchronicity, Jason Fried published an article on the same subject on Medium when I was writing this one. He suggests some ways to change the agreement on the use of communication tools that are important.

My recommendation would be to invest some time with the team to refine:

  • The use of communication tools: what needs to be covered by email, by instant messaging, in a chat room, or what needs to be covered with share documents that will help to build a common position. In each case, we need to define what are the agreed reaction delay
  • the way to protect the individual from interruptions: by accepting unavailability period, by synchronizing the whole team on the same schedule (harder if you are in several time zones), by dedicating people for a period to handle interruptions that we cannot avoid
  • to play a game to understand the power of focus (like the name game)

And about you, what are your strategies to let the people that are working with you to do their job?


The header picture is from Ryan McGuire.




The Five Dysfunctions of A Team

“If you can get all the people of an organization  rowing in the same direction you can dominate any industry on any market against any competition at any time.”

When the author use this quote from a friend in front of executives, they are all nodding, not only to express their approbation, but to express their inability to make it happen.

TheFiveDysfunctionsOfATeamSuccess comes to those who are able to overcome the human bias that undermine the teamwork.

The five dysfunctions of a team is a book by Patrick Lencioni (not a new one, but it’s often useful to re-read some “classics”). This book use a novel at the beginning to make easier to understand the ideas that are further reexplain at the end.

The five dysfunctions can’t be treated in isolation, the first one is the foundation of the next and so on.

TheFiveDysfunctionsOfATeam-2The five dysfunctions are, according to the author:

  • Absence of trust: unwilling to be vulnerable within the group
  • Fear of conflict: seeking artificial harmony over constructive passionate debate
  • Lack of commitment: feigning buy-in for group decisions creates ambiguity throughout the organization
  • Avoidance of accountability: ducking the responsibility to call peers on counterproductive behavior which sets low standards
  • Inattention to results: focusing on personal success, status and ego before team success

The author suggest tools to resolve each of the five dysfunctions. It’s probably there that the age of the book is visible as some of the tools had been overpass by others more recent and more effective.

Nevertheless, the model proposed by the book is useful to help a team understand what they will need to achieve to become an efficient team.

A book to recommend to many 🙂

You will also appreciate Rafael‘s review on goodreads (and all the others that will motivate you to read (or re-read) some books.

Header picture is from Adam Przewoski.