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 here. 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 the 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 on The Practice of Management by Peter Druker and proposed actions based on what he learned in the book. The results were good, and this fosters the idea to organize a book discussion club. The first book we chose: The Advantage. The book club was organized the day before the quarterly meeting of the leadership team.

And so we used the book as an introduction to our meeting, as a warm up 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 levels of understanding and adoption.

For example, retrospectives were strongly encouraged from the beginning. Some groups are sticking to 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 where 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 lead 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…


The 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 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:

Managing Time

When I searched for “time management” on google this morning, there were 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 to be 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 happens: 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 in 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 is 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 a 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 interactions 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?



The 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 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.

Town Hall Meeting

The term Town Hall Meeting is often used inside a company to characterize a meeting organized by a highly ranked executive and gathering a large part of the company employees, or even all of them.

Usually, the meeting is meant to give a short status on what the executives are working on for the future of the company and to answer some of the burning questions that have been heard in the hall way. Some of those questions have not been heard directly by the executives, but have been reported to them by some people. I have used two times the word “some” in the last sentence to give a sense of fuzziness, and uncertainty of what are the real concerns of people.

Let’s imagine that you are this executive, you have organized the meeting, you are ready for your speech, everybody is there. So now, you delivered your speech and you are ready for questions.

And, there’s no question.

Or, if there are questions, there are pushed by some manager, that want you to repeat what you already said, something that will reinforce their own beliefs, or positions.

In your speech, you have even gone further than what was planned to be said with your management team, and you have said that.

But still, there’s no question.

And, you know that there are unspoken questions. But the time is over, and there’s no way to know what are the real questions.

What is the problem?

Maybe the problem lies in the format itself. The Town Hall is not giving the sense to people that they can contribute to the thinking, that they can disagree. The Town Hall presents yourself in a position of power, with the authority to say yes or no.

Now, let’s say that you are a participant of the Town Hall Meeting.

At some point during the speech, you had one question. It was not really a question, in reality, it was more a slight disagreement. Maybe you wanted a clarification.

During the course of the speech, you have seen that effect reproduced 2 or 3 times. But that was not the time for questions.

And when the time for questions came, you cannot find a way to formulate all this in a meaningful way.

You even heard some of your coworkers said at the end of the meeting: “I bite my tongue because I really not agree with what Mr. Z said on this topic”.

Another option?

Maybe, If we want more interactions, if we want people to ask for clarifications when it’s time to do that, we need to use another format of meetings.

One of those formats could be a Fish Bowl.

In a fish bowl, the executive will not be alone in the center, so he can be joined in the fishbowl by some people in his or her management team. And it’s a moderated conversation, so topics can flow more freely from one or the other.

In addition, there’s an empty chair in the middle, and any person in the audience can sit on that chair to join the conversation at any time. When this occurs, an existing member of the fishbowl must leave the fishbowl and free a chair.

This way the clarifications questions and the slight disagreement could be covered at the moment they arise, and more questions and concerns can be covered.

Are you ready to try this?




The header picture is from Ryan McGuire.

Why Transformation Efforts Fail?

Thanks to a push email from Harvard Business Review, and discussions around ongoing transformation efforts, I read again an old article from John Kotter: Leading Change: Why Transformation Efforts Fail.

The first lesson is that change is not an event, it’s a process. The second lesson is that change takes time, and not following the change process could create an illusion of speed, but will result in failure.

If we study successful or unsuccessful changes attempt using the 8 steps proposed by Kotter, we could learn a lot on what we could improve in the future.

One aspect that is not directly covered in the 8 steps is what is called “Your organization”.

I learned from successful (and unsuccessful) changes, that defining “The Organization” is crucial. It will define who is part of the core group, and more importantly, who is part of the core group from the start.

Let’s say that in your organization, you have several teams that need to work together to deliver a product or a service, and you observe that they are struggling to deliver, they could even engage in politics and blame game.

If you engage with team A and team B. That could be, for example, because they are at the beginning of the production process, or for other reason, as you will always find great justification for what you did and cannot undo. I am smiling there, at myself, please don’t be offended.

You could work with those teams on step 1, and establish a sense of urgency. You could work on step 2, and form a group that will lead the change.

Now that you learned more on the production process, you can clearly see that team C, plays a crucial role, and needs to be involved.

As you are yourself driven by the sense of urgency, you could decide to involve team C for step 3. You could rationalize this shortcut as much as you can, but it will cause you a lot of troubles.

The best option is to go back to step 1, and work with team A, B, and C on establishing a sense of urgency, and continue the process from there. Until that restart, Team C will not see the same crises or potential crises, they will not see the same causes, and they will not want their future to be dictated by other teams.


The header picture is from Ryan McGuire.