Learning from the neuroscience of trust

Trust is the foundation of human relationship, and the foundation of an effective team. I recently share 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 still achievable goal, assigned to a team will intensify focus and strengthen 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 on what they will work will ensure focus and motivation. The author give the example of Valve, the gaming software company, I recommend their employee handbook to have an idea on 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.

This discussion could 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 Advantage of a book discussion club

The Advantage: Why Organizational Health Trumps Everything Else in Business is a book by Patrick Lencioni. This one is not a business novel, like The Five Dysfunctions of a Team (you may have read that previous post).

The book purpose is to explain a model to bring organizational health.

I will not enter into the details of the book itself as you can read a summary there. The goal of that post is to explain how we used that book with a leadership team I work with.

I like to read books, so I usually recommend books to read to others. I am using some books as theme for retreat meetings for teams. I used the Five Dysfunction of a Team for the first meeting of that leadership team.

A few weeks later, one other reader in the group, shared his reading notes of The Practice of Management by Peter Druker and proposed actions based on what he learned in the book. The results were good, and this foster the idea to organize a book discussion club. The first book we chose: The Advantage, and the book club was organized the day before the quarterly meeting of the leadership team.

And so we used the book as an introduction for our meeting, as a warmup for the retrospective. And also decided to answer the 6 questions below as a way to prepare our review of our Objectives and Key Results.

1. Why do we exist? The answer to this question will yield a core purpose, or the fundamental reason the company is in business.
2. How do we behave? This question examines behaviors and values required for success.
3. What do we do? This answer provides a simple, direct explanation of the business.
4. How will we succeed? This question requires the team members to develop a strategy.
5. What is most important, right now? The answer to this question is the establishment of a unifying thematic goal and action plan.
6. Who must do what? This question addresses roles and responsibilities.

A few weeks later, I can say that this was a really effective meeting, and we already chose the next book: Competing Against Luck from Clayton Christensen.

Something to try with your team?


Organization Maturity Model

The publication of the Open Organization Maturity Model reminded me that we had the goal to use a similar approach.

Why do we want to use a maturity model?

A maturity model is, as said on Wikipedia, “a measurement of the ability of an organization for continuous improvement in a particular discipline”.

So, our goal in defining such a model is to help a part of the organization to identify improvement opportunities. For that organization, we defined a specific organizational structure to serve it needs to curate and build technology in the open, and to deliver a tested and trusted product to serve the needs of customers.

The organization is composed of cross functional groups, with an emphasis on self-organization, and continuous improvement. The transition to that model shows different level of understanding and adoption.

For example, retrospectives were strongly encouraged from the beginning. Some groups are sticking to a 2 weeks scheduled retrospective enjoying the benefits, while other groups did not grasp how the practice could help them in improving their way of working.

Introducing a maturity model could help to focus on a limited set of characteristics, and could help the different teams to identify the one thing they want to focus on improving during their next cycle.

The maturity model is meant to be used by the team itself to self-assess where they are. It is not a measurement tool, and there’s no need to look shinier than you are. There’s nothing to be ashamed of. The results and the actions that you will take to work on one thing are specific to your group.

The main categories of the maturity model will need to be specific to our organization. And, for each group in our organization, the position they will find will be specific to them, and to what they are delivering in the organization.

If I take the example of cars, main characteristics could be:

  • speed
  • safety
  • reliability
  • efficiency
  • comfort

If one car is reaching a top speed of 20 miles per hour, we could want to improve it. But when it reaches 90 miles per hour, it is definitely not the area were the focus should be. It that case, I should probably have start with safety 🙂

So, introducing a maturity model, we are looking at conversations that will led to improvements.

The language used in the maturity model should reflect outcome, and not practices we would like to encourage. Looking a few paragraphs above, you will get why it’s important: if we are encouraging retrospective, we are pushing a practice and we could never get to the outcome we are looking at.

Thoughts on that? Recommendations to make?

Please comment, tweet, email…


Header picture is from Ryan McGuire.

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 remembered playing 2 times, with large teams, a game based on the game theory, and variant of the prisoners dilemma. The effects with one of the team were really great, for the one, where one of the participant 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/

Managing Time

When I searched for “time management” in google this morning, there was 238,000,000 results. So, we could consider that it’s not necessarily useful to add one more.

A quick look at the first page of results, and we can already see divergent opinions. From the rigid daily structure, to the statement that time management is ruining our life.

Let’s start with the most important first: why do we want to manage the time we have?

The common answer is: “To get things done”.

What are those “things” we want done? and why it’s important?

Because those things contribute to the accomplishment of a greater goal.

All that sounds really great! So, why do people are saying, from time to time, that they don’t have the time to do what they want?

As I fall myself into that kind of trap, I can try to list a few potential causes:

  • Knowing what you want and why you want it: if you don’t, the lack of time could be just a nice excuse? Writing down your vision of where you will be in the next 5 to 10 years on the different aspect of your life could be a good exercise.
  • Knowing what is the most important thing right now in order to make it happen: if you don’t, you want something, but you did not do your homework yet in order to make it happen, and so the question you need to answer is: What’s the ONE Thing you can do such that by doing it everything else will be easier or unnecessary?
  • Driving yourself: Maybe your calendar, or your inbox are driving what you are doing? If this is the case, you know what is the most important thing, but you are not doing it. One way to solve that could be to block some time, at the beginning of the day for the most important thing, and then only after that, choosing to invest time working on your inbox. Another important one is to empty your calendar, you will not be able to participate to everything and contribute to everything. Choose where your contribution is valuable.
  • Interruptions: multitasking is a myth, and so you want to limit the interruption during the block of time you are working on the most important things. The number of decisions we are able to make in a day are limited, so you don’t want to make decisions at each new notifications, new mail, new message on social media…
  • Care for yourself: you should have block of time to care for your body, to exercise, to meditate…
  • Invest in social interactions: you are not alone, and you need, as a human being, social interactions, so you probably want to invest in interaction that will have a positive effect on yourself, so you can have a positive effect on others.

I practiced the Pomodoro Technique in the past, and that definitely helped me to increase my focus on ONE thing at a time, and not to be fooled by my own estimates.

Maybe something to start with?



Header picture is from Ryan McGuire.

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 in 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 wrote 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 in 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 solving 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…




Header picture is from Ryan McGuire.