I mentioned earlier about “The Checklist Manifesto” book. The post was originally written in Portuguese but you can find a Google translation here. In this post I mentioned about the use of checklist in surgeries and other medical procedures and how we could use checklists in the IT environment.
I was reviewing my Kindle highlights for this book and found this highlight:
Surgery has, essentially, four big killers wherever it is done in the world: infection, bleeding, unsafe anesthesia, and what can only be called the unexpected. For the first three, science and experience have given us some straightforward and valuable preventive measures we think we consistently follow but don’t. These misses are simple failures — perfect for a classic checklist. And as a result, all the researchers’ checklists included precisely specified steps to catch them. But the fourth killer — the unexpected — is an entirely different kind of failure, one that stems from the fundamentally complex risks entailed by opening up a person’s body and trying to tinker with it. Independently, each of the researchers seemed to have realized that no one checklist could anticipate all the pitfalls a team must guard against. So they had determined that the most promising thing to do was just to have people stop and talk through the case together — to be ready as a team to identify and address each patient’s unique, potentially critical dangers.
Surgery has, essentially, four big killers wherever it is done in the world: infection, bleeding, unsafe anesthesia, and what can only be called the unexpected. For the first three, science and experience have given us some straightforward and valuable preventive measures we think we consistently follow but don’t. These misses are simple failures — perfect for a classic checklist. And as a result, all the researchers’ checklists included precisely specified steps to catch them.
But the fourth killer — the unexpected — is an entirely different kind of failure, one that stems from the fundamentally complex risks entailed by opening up a person’s body and trying to tinker with it. Independently, each of the researchers seemed to have realized that no one checklist could anticipate all the pitfalls a team must guard against. So they had determined that the most promising thing to do was just to have people stop and talk through the case together — to be ready as a team to identify and address each patient’s unique, potentially critical dangers.
Dr. Gawande found out that in order to address the unexpected, checklists should not only include task checks but also communication checks. Dr. Gawande got to that conclusion visiting a 700,000-square-foot office and apartment complex construction site with between two to five hundred workers on-site on any give day managed by a man called Finn O’Sullivan. The volume of knowledge and degree of complexity O’Sullivan manages is impressive and it was as monstrous as anything Dr. Gawande had encountered in medicine. Here’s the explanation:
It was also a checklist, but it didn’t specify construction tasks; it specified communication tasks. For the way the project managers dealt with the unexpected and the uncertain was by making sure the experts spoke to one another — on X date regarding Y process. The experts could make their individual judgments, but they had to do so as part of a team that took one another’s concerns into account, discussed unplanned developments, and agreed on the way forward. While no one could anticipate all the problems, they could foresee where and when they might occur. The checklist therefore detailed who had to talk to whom, by which date, and about what aspect of construction — who had to share (or “submit”) particular kinds of information before the next steps could proceed. The submittal schedule specified, for instance, that by the end of the month the contractors, installers, and elevator engineers had to review the condition of the elevator cars traveling up to the tenth floor. The elevator cars were factory constructed and tested. They were installed by experts. But it was not assumed that they would work perfectly. Quite the opposite. The assumption was that anything could go wrong, anything could get missed. What? Who knows? That’s the nature of complexity. But it was also assumed that, if you got the right people together and had them take a moment to talk things over as a team rather than as individuals, serious problems could be identified and averted.
It was also a checklist, but it didn’t specify construction tasks; it specified communication tasks. For the way the project managers dealt with the unexpected and the uncertain was by making sure the experts spoke to one another — on X date regarding Y process. The experts could make their individual judgments, but they had to do so as part of a team that took one another’s concerns into account, discussed unplanned developments, and agreed on the way forward. While no one could anticipate all the problems, they could foresee where and when they might occur. The checklist therefore detailed who had to talk to whom, by which date, and about what aspect of construction — who had to share (or “submit”) particular kinds of information before the next steps could proceed.
The submittal schedule specified, for instance, that by the end of the month the contractors, installers, and elevator engineers had to review the condition of the elevator cars traveling up to the tenth floor. The elevator cars were factory constructed and tested. They were installed by experts. But it was not assumed that they would work perfectly. Quite the opposite. The assumption was that anything could go wrong, anything could get missed. What? Who knows? That’s the nature of complexity. But it was also assumed that, if you got the right people together and had them take a moment to talk things over as a team rather than as individuals, serious problems could be identified and averted.
So next time you design a checklist, remember to include not only task checks but also communication checks.
Some time ago Rafael Rosa (@rafaelrosafu) presented me the concept of lifestyle startup in opposition to the growth startup everybody knows.
Growth startups – or companies- are startups that have one main objective, accelerated growth so it can make founders, investors and shareholders substantially rich when the startup is acquired or make an IPO. When you are focused on accelerated revenue growth, all your actions are driven by this goal, which has top priority on top of all other matters, including products, customers, employees, suppliers, quality, etc. Normal product question you hear in this type of startup is “how do we make this product sell more faster?” or “can we create another product or add-on feature to charge some extra money from existing customers?”. In this type of startup you tend to have people passionate about money.
Lifestyle startups – or companies – are startups where revenue has the objective to sustain the company and it’s founders and employees lifestyle. As soon as this issue (company sustainability as well as founders and employees lifestyle sustainability) is solved, the company can have full focus on product, customer, employees, suppliers, quality, etc. Normal product question in this type of company is “how do we make a great product that solves real customers problems?”. In this type of startup you tend to have people passionate about the product.
Sometimes it can be difficult to identify what type the startup – or company – is, but normally a conversation with the founders or some key employees around the topic of company purpose and people’s passion have good potential to help you identify the type of startup you’re dealing with.
Moving the point of view from the startup founder to the customer, i.e., use your customer hat and think as a customer. What type of startup do you think would you, as the customer, prefer to solve your problems?
People who read my posts knows I like to make comparisons between business world and medical world:
So here goes another analogy using the medical world. Move again your point of view and suppose you are a patient who received the news that you have a certain issue that requires surgery. What doctor would you choose to do this surgery, one who’s primary purpose is to get rich with medical practice or one who is really passionate about medicine and about making other people’s life better? Again, sometimes is difficult to identify the type of doctor we are talking to, but normally the way she describes your case and how it could be solved will give you hints on what type of doctor she is.
Ok. So back to my original question: what type of entrepreneur are you?
There’s a Seth Godin’s post that I always use as a reference:
Gravity is a constraint. If you’re a designing an airplane, it would be a lot easier without gravity as a concern, but hey, it’s not going away. A problem is solvable. A constraint must be lived with. … The art is in telling them apart.
Gravity is a constraint. If you’re a designing an airplane, it would be a lot easier without gravity as a concern, but hey, it’s not going away.
A problem is solvable. A constraint must be lived with.
…
The art is in telling them apart.
Source: Problems and constraints
This post always reminds me of that old saying that tell us pick our battles carefully. Specially if the battle is a constraint.
I mentioned earlier that one of the sources I’ve been reading and enjoying is Jurgen Appelo’s posts about agile management. I’ve been reading his posts for a while, since the time he was the CTO of a dutch company. I really like the way he connects agile methodologies and complex adaptive systems theory.
I’ve mentioned his work in 4 posts:
Now he is 100% focused on his agile management coach career. He recently launched a book entitled “Management 3.0: Leading Agile Developers, Developing Agile Leaders“.
He also provides Agile Management courses.
Last week he was in São Paulo providing his management course at AdaptWorks and I had the opportunity to attend his course.
I’ll make a brief summary of the course below, as a way for me to review what we discussed during this two days. However, I strongly advise any leader, even from non software related areas or companies, to attend. Even though the ideas and insights Jurgen provides during the course are very good and he is an excellent presenter, you can read them in his blog and in his book. What is great in this course is the opportunity to practice and discuss the ideas and insights with Jurgen and the other attendees and the chance to exchange experiences.
After a quick introduction about the ideal size of a group and quick introductions of the attendees, Jurgen explained quickly about agile software development and then introduced Martie, the Management 3.0 representation with the 6 aspects of management that we should take care if we want to be good managers.
Martie
Then Jurgen explained briefly about the theory of complex systems and the types of fallacies we may fall into if we don’t use complex systems thinking when managing teams.
The seven fallacies
To end the introductory section, we did a group exercise where we analyzed some situations to identify what was the fallacy in play.
When discussing about people, Jurgen talked about intrinsic and extrinsic motivation and presented us with the 10 intrinsic desires:
Intrinsic desires
Exercise time: we analyzed individually how we are in our current jobs in terms of each of these 10 intrinsic desires.
Then Jurgen presented some tools to helps us know what is important for the people in our team:
B = f (P, E)
Group exercise: we had to use the practices below to get to know 10 important facts about Ellen, a member of a fictional team managed by us.
Here Jurgen presented the 7 delegation levels I already mentioned in a previous post.
Delegation levels
Group exercise: delegation poker where we were presented with different situations where we needed to figure out the appropriate delegation level.
A leader must:
The 4 I’s to cope with the Tragedy of the Commons:
3 kinds of purpose (or goal) for a team:
Qualities of a good goal
Exercise time: we had to define a purpose for the course.
First Jurgen described how we can improve.
Competency development
Then he described how we can measure our improvement.
KPI matrix
Exercise time: we had to define KPIs according to the matrix above to our organization.
We can have two types of team organization, functional or cross-functional, it depends on how often team members need to communicate. Product managers, user experience designers and software developers need to communicate all the time about the project or product they are working on, so they need to sit together in a cross functional team. HR people on the other hand need to talk constantly to other HR people so they need to sit in a functional HR team.
Jurgen also advised we should hire generalizing specialists, promote informal leadership and widen job titles.
Exercise time: Meddlers.
Meddlers
How can I…
In order to change things we need to consider:
The system
The individuals
The interactions
The environment
Culture changes only after you have successfully altered people’s actions, after the new behavior produces some group benefit for a period of time.
John P. Kotter, Leading Change
Exercise time: each member of the group tell one story with she needs ideas on how to change, then the group select from the list above and discuss.
This is just a brief summary of the 2-day course, as a way for me to review what we discussed during. However, I strongly advise any leader, even from non software related areas or companies, to attend. Even though the ideas and insights Jurgen provides during the course are very good and he is an excellent presenter, you can read them in his blog and in his book. What is great in this course is the opportunity to practice and discuss the ideas and insights with Jurgen and the other attendees and the chance to exchange experiences.
I recently read the post “And” Leadership written by Jim Highsmith that caught my attention on using AND instead of OR:
One of the traits I think is very important [for an agile leader or manager] is that of “And” rather than “Or” leadership. The most pressing issues to face leaders are usually paradoxical; they appear to have contradictory solutions. Take for example the paradox of needing predictable delivery with that of needing to be flexible and adapt over the life of a project.
It’s easy to be an “or” leader. Pick a side and state your case loudly, over and over until the opposition gives up. It’s much more difficult to be an “and” leader, balancing between seemingly opposite strategies. However, in our ever-changing and turbulent world, slavishly following the “one right answer” is a recipe for disaster.
It’s interesting that in many situations in agile development we face situations where we initially think it’s an OR situation but when we analyze it, we realize it’s actually an AND situation where we need to balance apparently opposing concepts:
It’s interesting that this applies not only to agile development but to many aspects of our life. Should I be more concerned about my family or my job? Should I give more attention to my kids or my companion? Experiment changing or by and.
Next time you face a situation with opposing concepts, instead of choosing the easy path of taking sides and being an OR person, try to figure out a way to be an AND person. It will be much more difficult to ben an AND person. Sometimes it won’t even be possible to use AND in certain situations, but just trying to figure out if it is possible will be a good exercise with interesting outcomes.
Sometime ago I was talking to some friends from ThoughtWorks when one of them asked me why there are so few women in the IT industry? Specifically, why there are so few women in programming?
Since I’m an open water swimming aficionado my first reaction – quite naïve reaction by the way – was to attribute to the physical gender differences such as we see in sports. Women don’t compete with men in sports because there are physical differences. A women world record in any swimming event is different from men world record. But my friends replied that there aren’t any known physical differences that can justify why there are so few women in the IT industry. And they pointed out that the right direction for an answer was in the social and cultural realms. So I kept thinking about this topic, did some research and I want to share my findings.
I still don’t know why but my parents decided to put me in a male only school from 6 to 17 years old. My school decided to accept girls when I was 15. In my last year of school I had to choose between exact, bio or human sciences as part of the preparation for entering university. I chose exact science and my classroom of 35 people had only 2 girls. I started to realize that exact science and girls were not best friends. By then I decided to go to engineering school. I heard that there are not so many women in engineering schools and I went to visit some of them. I decided to go to ITA, a male only engineering school. It was a male only school because during their first year at ITA, the undergraduate students are required to attend a military preparation course once a week. This is due to ITA’s strong connection with the Air Force. Some years ago ITA decided to accept women. After graduating at ITA, I worked at 4 internet service provider companies and in all of them women was a minority, specially in the technical teams.
So the lack of women in exact sciences and technology has been part of my entire life, even though I haven’t paid much attention to this until recently.
First, diversity in general matters since diversity brings new ideas, new opinions and new view points. Differences always bring fantastic opportunities for learning and improvement. Recent research from National Center for Women & Information Technology (NCWIT) shows that diverse talent in the technology industry increases innovation, productivity, and competitiveness:
A recent NCWIT study shows that teams comprising women and men produce IT patents that are cited 26–42 percent more often than the norm for similar types of patents. In a study of more than 100 teams at 21 companies, teams with equal numbers of women and men were more likely (than teams of any other composition) to experiment, be creative, share knowledge, and fulfill tasks. Additional studies indicate that, under the right conditions, teams comprising diverse members consistently outperform teams comprising “highest-ability” members.
Anita Borg Institute for Women and Technology provides the business case for gender diversity:
The War for Talent – Remaining Competitive: Reaching out to technical women is crucial to a company’s ability to attract and retain the human capital it needs to succeed, and research shows: The cost of filling the vacancy of a skilled technical employee has been estimated to be as high as 120% of the yearly salary attached to that position. Despite popular beliefs about the impact of offshoring on hi-tech jobs, numbers show that the demand for high-level high-tech jobs such as software engineers has increased since 2000 and that offshoring has not slowed job growth in developed countries. Companies are looking for technology workers with more experience and a broader set of skills such as leadership and interpersonal communication skills. Competition for these employees, combined with the drop of computer science graduates and impending retirement of the baby-boomer generation, has led to fierce recruiting competition among firms; nearly 300 technology executives surveyed identified identifying, hiring, and retaining skilled technical workers as their top concern in 2006. Companies with effective diversity inclusion practices benefit from reduced absenteeism and employee turnover. Women have the skill set for the new competitive demands of technical work Companies agree that they need more technical leaders with varied skills such as interpersonal skills and business skills. 93% of technical leaders in a survey identified the building of collaborative networks in an organization as a crucial component of leadership. Women have the skills to meet the new demands of technological work both in terms of technical and interpersonal skills. Women are paramount to User-Driven Innovation Women influence 80% of consumer spending decisions, and yet 90% of technology products and services are designed by men. Including women in the technological design process means more competitive products in the marketplace. The most innovative companies design products through user-driven innovation by integrating lead users in the design process. Women bring new markets and new technological applications to the design process and can market effectively to women, opening up new lines of business. Women of various ethnic backgrounds can furthermore open new international and ethnic markets. Diversity brings benefits to an organizationís image Companies with a diverse workforce generally benefit from a better image in the marketplace. Diversity makes for better decision-making at all organizational levels Group diversity leads to better decision outcomes, and this has been shown in a variety of settings, occupations, and organizations, and also applies to group task performance and to creativity and innovation. Diversity is beneficial because a variety of opinions, backgrounds, and thinking styles and their integration into the solution are what contribute to better decision outcomes. Research has found a correlation between the presence of women in higher management and financial performance of the organization, as measured to total return to shareholders and return on equity. A recent industry report estimates that by 2012, teams with gender diversity will double their chances of exceeding performance expectations when compared to all male teams. Diversity is especially important and beneficial for problem solving and innovation tasks, such as is the case in technology.
The War for Talent – Remaining Competitive: Reaching out to technical women is crucial to a company’s ability to attract and retain the human capital it needs to succeed, and research shows:
Women have the skill set for the new competitive demands of technical work
Women are paramount to User-Driven Innovation
Diversity brings benefits to an organizationís image
Diversity makes for better decision-making at all organizational levels
Three weeks ago a read an interesting article on men and women in a Brazilian magazine called “Super Interessante”.
Cover of june's edition of a Brazilian magazine on men and women
Some interesting facts from the article:
Women earn 75% of men’s salary for the same type of work. 57% of the men negotiate their first salary. Only 7% of women negotiate their first salary. Men prefer jobs with performance bonus and competition. With friends, men talk more than women. However, when they are 1 year and 8 month old, women talk 2 to 3 times more than men. Also, girls are stronger, since child death is 22% bigger for boys. Women are 59% of the people who receives a university degree. In 2010 women are the majority of the American workforce.
Last week I watched a very interesting presentation entitled “Where Are All The Women?” by Erin O’Brien (@coolaunterin) via @sarahtarap and @dlbock that shed some light on the topic:
facts: general US workforce: 47% women and 53% men. computer and math occupations 26% women and 74% men. Women share is declining. computer programmers: 22% women and 78% men. open-source programmers: 2% women and 98% men.
facts:
possible explanations: stereotyped computer programmer image: Computer programmer stereotype a study in the university of washington where they introduced women into a computer science department classroom. If that classroom has images of startrek posters and videogame lying around women were less likely to show an interest in the computer science field. If that same classroom, still labeled as computer science classroom, has nature posters and phone booths lying around women were as likely as men to show an interest in computer science industry. it’s a two way street: women need to work to get into the field despite the stereotype people need to work hard to recruit women
possible explanations:
Computer programmer stereotype
Some advice for those who are trying to attract women to work in their companies: Don’t make your office spaces stereotypical. Fill your spaces with non-stereotypical images. Don’t assume all women like shopping, the color pink, or panda bears. There’s not a stereotypical female programmer. Don’t allow gender-specific job titles: mother, diva, princess, babysitter, etc. Use titles that speak to skill and attributes. Women work one hour less per week, but spend twice as many hours on housework as men. Women are not appealing candidates because of maternity leave, sick kids, school vacations, sick spouse. Hence, be flexible for ALL employees for family time. Networking is essential to further the career and networking normally happens in conferences which involves social aspects and traveling. This can be hard for a woman in an environment dominated by men. Additionally, it is bit harder for women to travel. Women tend to self-select herself out and to sell herself short. Organizations need to more flexible on their search for talent and women need to sell themselves more adequately. When men succeed they justify it with their ability and skill. When women succeed they justify it with luck. When men fail they justify it with bad luck. When women fail they justify it with low ability. Hence don’t reject a woman at the resume-level of selection. Give them the benefit of the doubt. Interview all of them even if her resume is not as good as some men candidates. She’s probably selling herself short. Women receive shorter letters of recommendation and lower job performance ratings. So use objective measures of job performance (e.g., # of widgets). Don’t use reviews to determine pay increases. 82 cents is not equal to a dollar. A woman gets paid 82 cents for every dollar a man gets paid for the exact same programming job. Don’t ask women why there aren’t more women in programming. Read blogs, articles, etc. by women in the field. Don’t ask a woman to speak for ALL women in the field. Ask men to speak to other men about the problem. Don’t assume a woman works in HR. Assume she is a programmer. Don’t point out the only woman in the room. Ask a woman how she got started in programming. Don’t assume a programmer isn’t a “real” programmer. Ask her what her favorite project is / was. Start them early! Be careful with language. Women have a natural aversion to risk. “Let’s hack this” may sound dangerous to a woman while it sounds cool to a man. Get involved with organizations helping women (.e.g., STEM – Women in Science, Technology, Engineering, and Mathematics. Don’t ask women out that you work with. Finally, inspire someone, guide someone, coach someone, mentor someone!
Some advice for those who are trying to attract women to work in their companies:
Checkout the full presentation.
Do you work to earn money? Or do you work to solve someone’s problem and earning money is just a consequence of the good work you did solving someone’s problem? Earning money is one of many indicators that you’re doing a good job, but you need to know what problem are you solving and why.
Recently I read a very interesting post written by Martin Fowler on the three pillars that serve as direction to ThoughtWorks. The three pillars came from Ben & Jerry’s mission statement:
In his post, Martin used the phrase “revenue is like oxygen – you need it in order to live but it isn’t what you live for” as a metaphor to explain the sustainable business pillar. I really like this metaphor but I would like to propose another one to help explain the sustainable business pillar:
Revenue is like food: you need it in order to live but it isn’t what you live for and; eating too much or too fast or the wrong food can make you ill.
Revenue is like food:
Too much revenue: how come too much revenue is bad? Well, there are many ways that too much revenue can be harmful. If you sell at a price too high, a person may buy one time, but she’ll have the feeling that she paid too much and she probably won’t buy again. Or if you sell more than what your able serve, your customer won’t be happy. Or you sell something you are not capable of delivering, again you won’t make your customer happy.
Growing revenue too fast: how come growing revenue too fast can be bad? If you are not prepared to sell fast, you may hurt your business by providing your customer with poor product or service. They won;t be happy, they won’t return, they won’t tell their friends good things about you.
Wrong revenue: is there such a thing as wrong revenue? If you have revenue due to the causes explained in the two items above, they can be harmful to your business. Besides this, other examples are revenue from an unethical sale or revenues that can create cash now but many operational problems in the future.
Next time you are chasing a new revenue, remember the analogy with food – your business need the revenue to live, but it doesn’t live for the revenue. Is this revenue enough for your business or are you trying to put too much food in your mouth? Are you acquiring this revenue at the right pace or you are being too fast and your company won’t be able to cope with the demand? Is this a good revenue or it may hurt your company in the future even providing some cash now?
P.S.: If you like this post, you may like Purpose Beyond Profit. And if you like analogies, you may like Leading is similar to being a doctor.
Those who has been following my posts know that I like to borrow ideas from medicine and relate them to software development an management. Below are two posts that make comparisons between medicine and software development and management:
By the end of February/2011 I was submitted to a cervical spine disc replacement surgery like the one shown below (it’s just an animation with no actual blood):
The result is in the x ray images below:
frontal x ray
x ray side view
The doctor did the surgery on February, 25th. However, the healing process will take months. According to the doctor, it can take one year until all the symptoms that motivated the surgery disappear.
What caught my attention is that the surgeon only did an intervention but all the healing process is done by the body. The same happens when a doctor prescribes a medicine, which is also an intervention, but again is up to the body to actually heal itself.
Leading a team is quite similar. The leader should do some interventions when necessary but is up to the team to do the work in order to get to the goals.
Leadership is topic that I really enjoy studying and discussing. It’s one of my top topics in this blog with more than 40 posts so far. And I already discussed about agile leadership in some of these previous posts:
In one of my reading session on leadership I found an interesting comparison between leadership and gardening made by Jurgen Appelo, who writes frequently about agile management:
I often compare managers to gardeners. An unmanaged garden is typically full of weeds, not beauty. From a biological perspective, there’s no difference. Either way, the ecosystem in the garden is self-organizing. It takes a gardener (authorized by the owners of the garden) to turn an anarchistic garden into something that the owners will enjoy. Likewise, it takes a manager (authorized by shareholders) to steer self-organizing teams in a direction that delivers value to the shareholders.
Even though I like this comparison, it considers that the gardener/manager has to constantly interfere, which I don’t believe is an appropriate behaviour for a manager. In my view, a manager’s interference should be done only when needed and, after the interference, the team should work by itself to solve things out with little or no intervention by the manager. Hence my comparison to a doctor who interferes only when needed by prescribing change of habits, medicine, physical therapy and / or surgery and who let the body do the work and be in charge of the healing process.
Next time you are in a team, either as part of the team or playing the role of leading the team, think about the leadership role similar to the doctor and the team work similar to the healing process carried out by the body. It helps understand the roles and responsibilities.
I just finished reading Tony Hsieh’s Delivering Happiness: A Path to Profits, Passion, and Purpose, an interesting book on Tony experience as entrepreneur and his findings along the way.
Delivering Happiness
The first thing he noticed is how important it is to have, to understand and to maintain a company culture. This is something I already covered in the posts below:
After the company culture topic, Tony discussed happiness and how it is connected with purpose. I’ve already discussed happiness here in the post named Hector’s list of happiness where one of the items of the list is “Happiness is feeling useful to others”. On another post named Purpose beyond profit where I mentioned the importance for a company to have a clearly defined purpose in order to be successful. What I found quite interesting in Tony’s book is the final chapter, “End Game”, where he wrote about his research on the topic of heppiness and the connection between people happiness and company purpose. First he explained the three type of happiness:
Pleasure The pleasure type of business is about always chasing the next high. I like to refer to it as the “Rock Star” type of happiness because it’s great if you can have a constant inflow of stimuli, bu it’s very hard to maintain unless you’re living the lifestyle of a rock star. Research has shown that of the three types of happiness, this is the shortest lasting. As soon as the source of stimuli goes away, people’s happiness levels drop immediately. Passion The passion type of happiness is also known as flow, where peak performance meets peak engagement, and time flies by. Research has shown that of the three types of happiness, this is the second longest lasting. Professional athletes sometimes refer to this state as “being in the zone”. Higher Purpose The higher-purpose type of happiness is about being part of something bigger than yourself that has meaning to you. Research has shown that of the three types of happiness, this is the longest lasting. What I find interesting is that many people go through life chasing after the pleasure type of happiness, thinking that once they are able to sustain that, then they will worry about passion and, if they get around to it, look for their higher purpose. 3 types of happiness Based on the findings of the research, however, the proper strategy would be to figure out and pursue the higher purpose first (since it is the longest-lasting type of happiness), then layer on top of that passion, and then add on top of that the pleasure type of happiness.
Pleasure The pleasure type of business is about always chasing the next high. I like to refer to it as the “Rock Star” type of happiness because it’s great if you can have a constant inflow of stimuli, bu it’s very hard to maintain unless you’re living the lifestyle of a rock star. Research has shown that of the three types of happiness, this is the shortest lasting. As soon as the source of stimuli goes away, people’s happiness levels drop immediately.
Passion The passion type of happiness is also known as flow, where peak performance meets peak engagement, and time flies by. Research has shown that of the three types of happiness, this is the second longest lasting. Professional athletes sometimes refer to this state as “being in the zone”.
Higher Purpose The higher-purpose type of happiness is about being part of something bigger than yourself that has meaning to you. Research has shown that of the three types of happiness, this is the longest lasting. What I find interesting is that many people go through life chasing after the pleasure type of happiness, thinking that once they are able to sustain that, then they will worry about passion and, if they get around to it, look for their higher purpose.
3 types of happiness
Based on the findings of the research, however, the proper strategy would be to figure out and pursue the higher purpose first (since it is the longest-lasting type of happiness), then layer on top of that passion, and then add on top of that the pleasure type of happiness.
Source: Delivering Happiness: A Path to Profits, Passion, and Purpose
Then he goes on explaining fractals, rough or fragmented geometric shapes that can be split into parts, each of which is (at least approximately) a reduced-size copy of the whole (source: Wikipedia):
Computer made fractal
Real life fractal: Jupiter
Real life fractal: leaf
Real life fractal: lung
Real life fractal: tree
And then he explains how similar the three types of people happiness are to the three elements that is found in great companies, just like in fractals:
I think the parallels between what research has found makes people happy (pleasure, passion and purpose) and what the research has found makes for great long-term companies (profits, passion and purpose) makes for one of the most interesting fractals I’ve ever come across. Happiness and business
I think the parallels between what research has found makes people happy (pleasure, passion and purpose) and what the research has found makes for great long-term companies (profits, passion and purpose) makes for one of the most interesting fractals I’ve ever come across.
Happiness and business
So here’s a few questions for us to think about:
