A short article to publish the video recording and the slides of the talk I gave today at the OpenStack summit in Austin.
Header picture is from Ryan McGuire.

A short article to publish the video recording and the slides of the talk I gave today at the OpenStack summit in Austin.
Header picture is from Ryan McGuire.

I usually ask for feedback regularly during the meeting I facilitate. I use several techniques to do so depending if it’s a short feedback before a break or if we have more time at the end of the meeting.
One of those techniques is the ROTI, the Return On Time Invested.
I ask the participant to evaluate with their 5 fingers. If their time was well invested: 5 if their time was well invested, they have learned and contributed, 1 if it was not the place they should have been. I am asking them to answer the question all at the same time.
The name itself should led the participants to understand that I am asking them to value the investment of their time. I am not asking them to evaluate me, or to give me a grade. But it’s not necessarily working this way each time.
One thing I have tried after listening to Heiko Fischer is to tweak the question a little bit.
I am asking the participants to evaluate how the meeting was awesome on a scale
from 1 to 5?
I let the people being cynical about it…
And then ask a second question: On a scale from 1 to 5 how did you contribute to make this an awesome meeting?
The learning there is that there’s no magic, the meeting is a result of our commitment.
Obviously, it’s not needed in all environments, but sometimes it could be useful.
Header picture by Ryan McGuire.

Beyond Measure: The Big Impact of Small Changes is a book by
And it starts with:
Trust
The author suggests an exercise for team members. Form pairs in which one will ask a real question and listen for 5 minutes: “Who you really are?”, “What do you want in life?”. Silent listening, maintaining eye contact for 5 minutes is a great exercise. And then we switch role for another 5 minutes.
I already tried similar exercises using appreciative inquiry to start workshop or training with people that don’t know each other well. I can attest this is efficient!
Trust between team members is a prerequisite to developing our ability to talk about our mistakes and to develop our capacity to learn from those mistakes. This foundation for effective teams is also covered in this article: The Five Dysfunctions of a Team.
Social capital
Margaret introduce the notion of social capital with:
“The dynamic between people is what brings organization to life.”
She explains the importance of the time spent together at work, during breaks or lunch. She gives an example of the decision to synchronize breaks in a call center that dramatically improved the performance.
Interruptions
If some time needs to be dedicated to interactions between people, quite time needs to be organized to allow concentration. I already covered this topic in a previous article: Let us Code. One of the example given is a scientific study that shows the danger of multitasking. People are shown a video recording – in a typical news channel format – of a CEO explaining the strategy of a company. People are told to focus their attention to the sequence as there will be some questions to answer after that. They have been asked to give their opinion about the strategy… And if they were able to remember some information, together with not relevant ones about weather, stock quotes, other news alerts, that were displayed on the multiple banners… They were totally unable to criticize the strategy. The conclusion of the study was that multitasking prevents us to think. Quite scary if we think about who are the people addicted to multitasking in organizations.
Rest
The author also quotes other studies on work day duration (more than 11 hours a day lead to depression) or necessity for the brain to rest at least for 7 or 8 hours a day (less lead to reducing the ability to think).
Leadership
Margaret explains the Pygmalion effect: expect great things, and they will more probably happen. This reminds us the importance to define ambitious goals, and to believe in the ability of people to reach those goals.
She encourages also to get rid of silos, and to empower people, to accept that leadership needs to be fluid, linked to skills and not to titles and ranks… Title and ranks could lead a part of the people (unfortunately the majority) to think that they are not good enough… And the Pygmalion effect will play in a bad way.
She recommends to people to choose to make some space for their contribution, even if it’s not their job or their role, just because it’s their life.
The author also gives the example of check lists, that reduced by a third mortality in hospitals as a way to take the power from a few to empower the many. This has been covered in another article: Black Box.
When we accept that there are talented people everywhere, people will think not only about the work to be done, but why we need to do it, and how to do it.
When you have done what is needed, Ask yourself what one more thing you could do to make those people happy?
A book to read (or to listen) and you could start with a TED conference given by the author:
La photo d’entête est de Ryan McGuire.

Some time ago, I add a card in the inbox column of my personal GTD kanban board (I can share the model if needed). The card was labeled “Standing Desk”.
During the next review, I moved this card in the “Someday / Maybe” column. And the card sat there for… nearly ever.
During the same week several factors made me reconsider this card:

So, I moved the card directly to the to do this week column, look at the options and decided to change my whole desk (I bought the previous one 20 years ago) and chose the IKEA Berkan model.
With this desk I can have my whole set-up moving. The first week, I thought it will really help me to “not forget breaks” and to “not forget to change posture” as it was difficult for me to stand for long, so I alternate sitting and standing position during the day.
After 2 weeks, I can stand longer, the cat is using my chair, and I need to be sure to start my pomodoro timer to remember to have a break and to change posture. The fact to stand has a good impact on my numerous conference call during the day: I am able to close the call faster. The same effect that leads to decide that a daily synchronization meeting should be done standing up, this way it could be shorter (There’s a study on that effect here).
I recommend you to test, and you will probably adopt it!
The day I received my IKEA desk, Lisette Sutherland published a post showing her desk, probably the same model in another size! By the way, if you are interested in collaboration and remote work, follow her!
Header picture is from Ryan McGuire.

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

Work Rules is a book from Laszlo Bock, SVP of People Operations at Google. You will find that the “People Operations” that could be called “Human resources” in other organizations is really different in its way to operate.
Main difference is the focus on data, not on opinion, and to be careful with natural human biais.
They decided to measure everything that concerns people and their interactions. They started with the recruitment process, and analysed how the numerous interviews and tests was not able to eliminate interviewer’s biais. They changed the way interviews was conducted and continue the measurement to see what was working or not.
Brain teasers appeared not so useful. They probably demonstrate that the one who is asking the question is smart, but they will not help to find the right people for the organization. Asking questions that help people to share their behavior is much more interesting. For example: “Tell me about a time your behavior had a positive impact on your team” and “Tell me about a time you had difficulty working with someone”.
Their recruitment goal is: “Only hire people who are smarter than you are, no matter how long it takes to find them”.
They also improved employee surveys and gave analysis capabilities to managers and employees.
One of the things that I found particularly interesting – and one of the thing I try to put in place with every team I work with – is the peer feedback. They improved and simplified radically their system to reach 2 questions:
A benevolent way to help people grow.
You will discover also things that I already covered on this blog, like the way to thank people, to send kuddos. They have G-thanks (that doesn’t need manager’s approval) and they also have 750$ peer bonuses (that doesn’t need managers approval either).
Of course, the author covers the way to set goals with the OKR approach. You can have a look to the re:Work guide designed by Googlers to learn more on this.
I encourage you to read the book, to read this illustrated summary. And to intrigue and give you really the desire to do so, I will share the summary in 10 points:
Header picture is from Jason Yu.

LessPass is a password management system based on a completly different idea compared to existing solutions.
Most of the solutions are based on a centralized storage of password protected by a master one. The centralized storage can be basic, like a spreadsheet on your own computer or on a server. It can be a little bit more complex like commercial solutions available nowadays.
LessPass is different is the sense that it will not memorize any of the password. The system will only generate the password based on the informations you will provide. You don’t need to trust someone else to keep your password safe.
Of course, the project is open source, the code can be audited. And, there’s no tracker on the website (you can check that with Privacy Badger for example).

The Chimp Paradox is a book from Steve Peters subtitled: The Science of Mind Management for Success in Business and in Life.
I used the model proposed to represent how our brain is working during conferences I gave on the Search for Happiness, and I had some positive feedback.
In this article, I would like to give you a little more and invite you to read Steve Peters’s book.

This book is an exploration of a solar system. The sun is the place you wanted to be. The planets represent zones to explore like: yourself, others, communication, stress, success, happiness, trust, security.
The first planet is divided. It represents our mind, our way of functioning, the battle between our human and our inner chimpanzee.
The model proposed by Steve Peters is simple and is composed of three parts:
If we look at the way a responsible human being will deal with a situation. He will first look at himself, what he has done to generate this problem. Then, he will look at the circumstances and their impacts on the situation. And after, he will look at others and search for ways to help them change their behaviors.
If we look at the way a chimpanzee will deal with a situation. It will be less rational and much more emotional, and it will work in the opposite direction. The chimp will first look at others and finger point at what others have done, then it will look at the circumstances and blame them, and in the end, it will look at himself with pity.
A human being has to live with an inner chimp that will wake up fast (5 times more quickly) each time it feels danger and will take over the thinking with the 3 F: Fight, Flight or Freeze.
The chimp is ours. It’s a part of ourselves given at birth. We cannot say: “Oops, sorry, it’s my chimp.” Like if it was our dog, we are responsible for it if the dog bites someone.
The third part of the model is the computer. The computer, 20 times faster than the human, will take over to handle known situations. So, it will relieve us of a lot of thinking. That explains why, in some circumstances, we react and then think: “why did I say that?”.
The problem is to whom we want to delegate computer programming: the human or the chimp?
After introducing the model, the rest of the book studies ways to manage our inner chimp and to reprogram our computer with the human.
The header picture is from Matthew Wiebe.

Next OpenStack Summit will be in Austin in less than 70 days.
You can vote for your preferred sessions following this link.
I submitted two talks: the first one will cover what science knows about happiness that could transform OpenStack and the second one with Mark McLoughlin will study how organization can increase the impact of their contributions inspired by practices, principles and values of opensource and agile projects.
To vote for those sessions:
Voting closes Wednesday, February 17 at 11:59pm PST (February 18 at 7:59am UTC)
Thanks for your support!

Once more, I have been to a conference given by Jean-François Zobrist. It’s always the same ; he tells what he have learned during the years he was managing FAVI ; and it’s always different as he adapts the content to the audience.
This conference was organized by Germe Bordeaux groups at ISG. Germe started as an initiative of APM, a not for profit organization regrouping entrepreuneur’s local clubs to improve their management practices. Jean-François Zobrist tell stories connected to what he has learned during APM or Germe’s sessions.
This post to deliver one of those stories, and to invite you to met him in a conference or to read what he wrote to transmit all the learnings
So, the story. During one session organized by Germe, they invited a nuclear submarine captain to explain his management role. They were really surprised by the fact that the captain is not supposed to do anything in the day to day of the submarine. He could spend all his days in his cabin without being disturb by anyone.
What if an “enemy” submarine was just crawling in front of their nose? The team would not disturb him as they know perfectly what to do in those kind of situation. But if a shoal of fish looked really too similar to a shoal of fish for the board instruments, then they will probably call him.
This short story shows the importance to setting an efficient system (people, teams, organization, processes…) and to let this system work, and at the same time listen to weak signals that will drive today’s actions or tomorrow’s innovation.
He explained that when a surgeon was explaining the challenge of heart operation was to deal with the clock, because of the growth of microbes. Favi started to look at this problem and develop new antimicrobial alloys.
Header image is the “Typhoon3” by Bellona Foundation. Licensed under Copyrighted free use via Commons.
I hope that 2016 will bring you joy and that you will have the opportunity to bring joy to others!
Joie means joy in french. This nice picture from David Hermans express the wish well.


I have been asked by Philippe Honigman to answer 2 questions about open source collaboration to help him on one of his projects.
I was wondering what could be the questions not already answered thousands of times. This curiosity led me to an interesting conversation, with interesting insights I would like to share with you.
First question: What’s the hardest part about rewarding a community supporting an open source project?
There’s a lot of different motivations and rewards you can find contributing to an open source project. The first one could be the product or service you are contributing to. The motivation and satisfaction to contribute to a greater good. The fact that collaboration with others, will improve the quality and security of the product.
There’s also a lot of learning opportunities. Because the code base is public (in case of software development) you can learn how the others are solving problems when you review the code, you can also benefit from the reviews of others. All this could also lead to interesting employment opportunities.
Some people will work hard to increase their reputation, to gain status or authority on a project.
So, the hardest part about rewarding the community supporting an open source software could be first to understand the motivations of the contributors and to adapt the reward to the motivation.
Second question: What’s the hardest part about making decisions in open source project?
The question around decision is an interesting and also a tough one. Some of the mechanisms are really collaborative and we can say that the best ideas win. But sometimes, decisions based on authority gained in the past seem irrelevant, or even totally ego-driven
The organization of some open source project are quite traditional and hierarchical with board, technical committee, and a hierarchy for sub-projects. Even if the people are co-opted or elected by their peers to gain authority and status, it is still a hierarchical structure.
Hierarchies emerge because of our limited understanding of decision-making processes. We are looking for someone who will ultimately “take” a decision.
In some organization where there’s no arbitration mechanism, nobody to decide, people tend to become more reasonable and start making decision and avoid letting their ego undermine the collective effort. Those people have learned how to make it happen.
We continue the conversation about different kind of organizations and decision making process. And then, we came back to the first question… I (intentionally) forgot to speak about money and value sharing because I don’t really have a solution to propose that really satisfies me… People that contribute to open source project are often employed by a company that needs the product / service, and when they are not, some of them are looking for an employment opportunity… For the others, some of them have another source of revenue, and are OK with the other rewards.
That’s the aha moment when Philippe explained me the ideas they had, to tackle the reward questions for contributions and to be able to distribute the decisions avoiding the effect to have a concentrated power in the center.
They want to use the powerful blockchain technology popularized by the bitcoin experiment. I’m saying “experiment” because the Bitcoin is a particular application of the blockchain technology.
This short video can give you a little overview of what blockchain is about:
If we use the blockchain technology to create distributed services, we can create a car sharing service with no centralized control, like LaZooz. So the people who are sharing the goods / services are doing well and it benefits to the community of people involved instead of being confiscated by a platform like uber, airbnb, blablacar…
We can imagine to use the blockchain technology to facilitate the decisions making process in an open source project and to reward the contributors according to the value of the contribution and the risk they are taking when they join a project at an early stage for example. More on those ideas, if you look at http://backfeed.cc/ and https://www.ethereum.org/
Lessons (re)learned:
Comment and share this article if you like the reading 🙂
Header photo by Tim Swaan