Success is not a matter of mastering subtle, sophisticated theory, but rather of embracing
common sense with uncommon levels of discipline and persistence.
Why I read this book?
Teamwork is something that I’ve always been hearing a lot about, but also something I haven’t had a practical
need for up until recently. What changed was I started working with a team on the real-world projects.
Most of my education did not require teamwork and what was evaluated was the skill of an individual.
Thus I haven’t been giving it too much thought at that time. I just assumed good teamwork is something that comes naturally
when a group of people with the appropriate skillset agree to work together on something.
Having started collaborating with other people, I for the first time experienced how important and beneficial good
synchronization between team members (and how destructive the lack of it) can be.
I also felt I was missing the vocabulary to express why is a particular situation “good” or “bad” and was trying
to establish a mental framework that would help me classify, understand it and act properly.
When I saw this book recommended by a colleague of mine I hoped it might provide just that,
and I wasn’t wrong.
What is it about?
The most of the book is the story about a fictional tech company that despite having unmatched technology and talent
still consistently keeps falling behind the competition. The reader is brought into the story at the moment when the
company board decides to introduce a new CEO with a task to fix the executive team.
The author explains all the concepts through the story as the new CEO introduces the model of “5 dysfunctions”
and works together with the team on addressing them one-by-one.
Book closes with a chapter that succintly defines the model and each of the dysfunctions - why it occurs,
how to identify and address it.
The model identifies five dysfunctions that occur within a team, where the existence of one
enables the others in a cascading manner:
Dysfunction #1: Absence of Trust
In the context of building a team, trust is the confidence among team members that their peers’ intentions are good,
and that there is no reason to be protective or careful around the group.
In order to achieve this kind of trust, we need to overcome our need for invulnerability. Meaning that team members
must be confident their mistakes and weaknesses won’t be used against them.
This is something like “overcome your ego”, “don’t be afraid to admit you don’t know everything” stuff everybody talks about.
But here it is very precisely explained why it is important, and what are the consequences in failing to do so.
I also like how author explains why it is so hard to overcome this dysfunction - we’re throughout our whole education
taught that making mistakes is something to be ashamed of, while in the uncharted entrepreneurial territories it’s basically
the main learning tool.
Dysfunction #2: Fear of Conflict
If we don’t trust one another, then we aren’t going to engage in open, constructive, ideological conflict.
And we’ll just continue to preserve a sense of artificial harmony.
This is in a nutshell why it is important to achieve trust. The author also stresses down the importance of conflict and that
it’s presence is absolutely neccessary in order for a team to grow.
I also found useful this definition of the constructive conflict:
Ideological conflict is limited to concepts and ideas, and avoids personality-focused, mean-spirited attacks.
However, it can have many of the same external qualities of interpersonal conflict—passion, emotion, and frustration—so
much so that an outside observer might easily mistake it for unproductive discord.
If members of the team are not encouraged (or are even afraid) to express their opinions, that will lead them into the next
Dysfunction #3: Lack of Commitment
It is important to remember that conflict underlies the willingness to commit without perfect information.
In many cases, teams have all the information they need, but it resides within the hearts and minds of the team itself
and must be extracted through unfiltered debate.
Only when everyone has put their opinions and perspectives on the table can the team
confidently commit to a decision knowing that it has tapped into the collective wisdom of the entire group.
Once a person feels confident his arguments have been listened to, he will much easier support the final decision even if it isn’t
his first choice.
The benefit here is that the team will be able to reach a decision faster. Even if it is the wrong one, it is often better than
stalling and it’s easier to change direction without guilt.
Dysfunction #4: Avoidance of Accountability
More than any policy or system, there is nothing like the fear of letting down respected teammates that
motivates people to improve their performance.
Once the whole team is committed to the plan that is clearly defined it is much easier to hold somebody accountable.
The author also described an interesting phenomenon: team members who are close to one another may hesitate calling out on each
other in order to preserve their valuable relationship. But the end result is exactly the opposite: they begin to silently lose
respect for a colleague since he hasn’t lived up to their initial expectations.
Dysfunction #5: Inattention to results
The ultimate dysfunction, that comes as a consequence of the all previously listed, is that team members don’t care about
the collective goals of the group, but rather concentrate on fulfilling their personal goals.
It is helpful to publicly proclaim results that are to be achieved and clearly define what metrics will be used to define
Teams that are willing to commit publicly to specific results are more likely to work with a passionate, even desperate
desire to achieve those results. Teams that say, “We’ll do our best” are subtly, if not purposefully, preparing themselves for failure.
Intangibles to share: Knowledge, Network and Compassion.
Author defines these three as “intangibles” - something that each of us owns and can share it with others without
losing it. In fact, more successfully we share more we receive in the return.
I love this point of view and found it helpful in understanding how to develop meaningful interactions through
providing value, both in personal and professional relationships.
Knowledge is in books
Books give you knowledge. The news gives you awareness. The latter is a measurement of today.
Knowledge is a measure of yesterday, today, and tomorrow. Awareness is finite. Knowledge is forever.
This quote (and the whole chapter) argues fact-based knowledge vs. understanding-based knowledge. While news
provide most recent facts, they are not meant to be a source of ideas and inspiration. This is where books step
in - although the facts may be outdated (this book was published in 2003), the concepts and lessons in it hold
for much longer.
Also, people by nature enjoy to share what they know with others and get a sense of accomplishment and earn credibility for it. But, in fact-sharing business the competition is much larger because facts are so
easy to find and it’s only a matter of luck from whom you will find out the result of last night’s game.
It is more valuable to listen first, and then share ideas that people can apply in their specific
situations, to provide them with a new perspective that they haven’t thought of before.
To help them help themselves.
Develop a reading system
I found it interesting how author puts a lot of focus on developing a reading system that helps him to be more
aware of what he is learning, and think this is a good idea.
He developed his own system that he calls “Book Cliffing” - what he does is he tags the parts he finds useful and
also writes a mark in the front blank page about it.
The end result is a short summary of the whole book which is useful if you want to quickly remind yourself of a
Since I’m mostly reading books in electronic format this technique is not directly applicable in my case, but I
love the idea of writing down key takeaways with purpose of fortifying acquired knowledge and storing it for later
use. This is actually the reason I write these posts, but I’m also looking forward to further
developing my reading system.
Network and Compassion
There are two more chapters about Network and Compassion, but I mostly focused on the first one as
it was the most innovative for me. While the other two also offer great ideas and insights into
old-fashioned corporative way of thinking, I feel they are being much more promoted nowadays,
especially in the startup community so I was more familiar with them from the start.
How to apply all this to blog posts?
As another great source of knowledge and actionable ideas I find blog posts, particularly in the area of
self-development and entrepreneurship. Their peculiarity is in that each blog post from a certain series
(e.g. Groove’s Startup Journey
or Nathan Barry’s ConvertKit story) can act as a
stand-alone piece of content and it’s hard to summarize what is already pretty much summarized by itself.
The whole concept is also very interactive and “lean” since readers immediately provide their feedback and point
what they would like to learn more about.
There is a ton of awesome blog posts on various topics and I would love to have a way to
systemize that knowledge and keep a track of what I read and what I’ve learned from it.
I found out about this book while watching the recording
of the talk on the same topic, given by Frank Rimalovski at Lean Startup Conference.
I found the talk interesting, and liked the example-rich way Frank used to deliver points to the audience. At the end he
announced that everything he presented and more can be found in a newly published book
Talking To Humans, which is also completely free to download!
This is not the first time I’ve heard about customer development - I’ve actually been very actively involved with it on the projects
I’m currently working on.
Still, reading this book made me reevaluate and reinforce my knowledge - going through chapter by chapter I could pinpoint things
I was missing on and better understand their importance.
If you want to learn about customer development, here are some great resources I can recommend:
All in all, this was fun and easy to read material, and here are my main takeaways:
Do. Observe. Ask.
I like how the author divided customer dev process into these three components. I used to associate it only with the
“Ask” part, in other words interviewing people. Having read this, I realized I’m already doing a lot of observing, just didn’t think
of it that way.
For example, I like to collect the examples of how people currently deal with the problem we’re trying to solve. That way I
gain understanding of what is important to them, and also why. At the same moment I identify the potential early adopters - if they are
dealing with the problem, it must be important to them.
“Do” means trying to experience the targeted problem yourself, and later also using the solution yourself. I think this is really
important, and would love to practice this more.
Ask for referrals.
As the author says, make it happen - this is one of the secrets of “growth” in this stage as you are much more likely to get a
response, opposed to sending a cold mail. That’s so both because you’ll get an introduction, so your contact won’t be cold anymore,
and because your referrer will do her best to connect you with the people who are truly interested in what you’re doing.
Here’s an example of how I do it:
I find it very beneficial to learn about this problem from a different perspectives. Could you recommend anybody else to whom I could
If you already have a value proposition or even a product that you’re testing, you could go with something like this:
Do you know anybody else who might find our solution beneficial? I find it really valuable to talk to the experts like you and learn
how to improve our product.
Focus on early adopters first.
Note to myself:
New founders tend to obsess about their mainstream customer. However, by definition,
the mainstream is waiting for proof from early adopters before they trying. If you cannot
get early adopters, you cannot move on.
And here’s the definiton:
Early adopters are usually folks who feel a pain point acutely, or love to try new products
I also think about early adopters as of people who could not only benefit from the solution you’ll develop,
but are also truly excited about it, and interested in how you’re going to solve it.
I’ll leave you with a great 1-minute video by Steve Blank
who makes a point much better thank I could say it:
These are the people who see your product even better than you do. They see the finished product 18
months from now, even though you didn’t show it to them - because they’ve been thinking about solving the
same problem for themselves for years, and then you showed up.