Culture Hacking

Torii gateCulture Hacking is the systematic design and implementation of team practices, commitments, and viewpoints that yield desired results. In other word, it’s about hacking your own culture. This is an idea I got from Jim McCarthy.

Culture Hacking is an art. It’s also an empirical process – you have to make a change, see what works, make more changes and so on. Culture hackers each have their own aesthetic and also share techniques, practices, and “culture software” like the Core Protocols, Scrum, Lean, and so on.

Some culture hackers work on methods that can be shared between teams; others work on the culture for specific companies. Some, like the Core Protocols, are applicable to both.

Culture Hacking as a field or discipline is at a level above individual systems. Culture hacking at its best is about creating cultures that enable people and teams to achieve greatness. Culture hackers combine and edit cultural systems, practices, values, and viewpoints, try them to to see if they work and share them with others. They do so systematically, rationally, and in the spirit of play.

Culture hackers see culture as software, and as such think that it has many characteristics of software:

Grameen Foundation Boot Camp in India

  • ease of use
  • reliability
  • interoperability
  • extensibility
  • compatibility
  • portability
  • adaptability
  • scalability
  • and so on…

Culture hackers see that culture has a viewpoint, an architecture, and an internal structure. Culture hackers see culture as something they can modify and improve on.

Culture hackers operate at different scales, sometimes simultaneously – on the level of internal experience of an individual; on the level of individual behavior; between two individuals; or between a team of three or more. Culture hackers operate on teams inside companies and outside them, on the level of one team or many teams, and even at the level of whole societies or even groups of societies.

It almost goes without saying that culture hackers like trying on new things. They are okay with being uncomfortable in a new culture that they have created or that they are trying out for the first time.

When I was talking with Jim, he wondered, “Where is the culture hacker’s version of the Homebrew Computer Club? Will there be culture hackers like Woz? Like Bill Gates? Like Steve Jobs? Like Bill Hewlett and Dave Packard?”

I find that many people I admire were culture hackers: Gandhi, Martin Luther King Jr., and Nelson Mandela. But I think the future is with the culture hackers who aren’t famous yet – and those who may never be famous.

The startup scene today is composed mainly of people who are doing proprietary culture hacks on their own teams and companies. But there are also people that I admire working in the open: Jim McCarthy, Steve Blank, Larry Lessig, Eric Ries, Kent Beck, Ken Schwaber, and others are working on Open Source culture – team, company, movement, or political culture that others can adopt, share, and build on. The Startup Genome is a team of culture hackers trying to systematically crack the code of what makes companies and teams successful. Creative Commons is a successful culture hack that operates on the level of a society. Lessig is working on another culture hack now, Root Strikers, an effort to re-engineer American society to eliminate political corruption.

Clock of the Long Now
These folks show that it does really help to share what you know, and you can make a difference by working in the open with others. If we are to survive into the Long Now, the next ten thousand years and beyond, we’ll have to to be able to engineer human cultures that help us embody the qualities we want – kindness, integrity, foresight, beauty, innovation, democracy – rather than those that encourage qualities we don’t want – greed, violence, lying, stagnation, concentration of power.

If you tweet about this, mark your posts with #CultureHacking so that people can see the movement build.

It starts with you. Let the culture hacking begin!

Ways To Get What You Want

Getting what you want is the essence of leadership, and that is what I want to talk about in this article. I wrote it for my partner Lena when we had some difficult conflict to resolve. I thought it might be useful for other people.

But before I get to what to do, I want to say what not to do.

Don’t complain.

Zen Garden somewhere in KyotoComplaining is unhelpful because the complainer wants others to solve the problem. When you are having conflict that does not feel productive, it is often because one or more parties are complaining, wishing others would solve the problem for them.

Complaining also contains the wisdom of communication – since the complainer is trying to communicate with others to get resolution. Complaining often has the spirit of anger, another wise quality, since anger can help motivate people to work for change. Since the anger is directed at other people, though, it is not an optimal problem-solving strategy. Anger is helpful when directed at problems or situations.

Don’t avoid or attack.

Avoiding is another well-used but unhelpful problem-solving strategy. The main thrust of avoiding is the hope that someone else will solve the problem or that it will go away by itself. This rarely happens.

Avoidance’s wisdom is in self-control – carefully considering a course of action is known to be helpful, while taking rash action often leads to suboptimal solutions or even disaster. Too much inaction, though, causes problems.

While avoiding is passive-aggressive, attacking is directly aggressive. It’s suboptimal because it is about stopping action via non-rational means.

The wisdom in an attack is that of engagement with another person or idea. It’s best to engage using rational means, as non-rational engagements can often cause damage.

Don’t fall into self-pity.

Self-pity is similar to complaining, except that the subject of the complaints is oneself. This unproductive strategy is designed to get other people to solve the problem, or to solve the psychological problem of explaining to oneself why the problem exists. It is a cross between complaining and avoiding – since the complaints are directed at oneself, but no productive action is being taken to solve the outward problem.
Emerging from a tunnel
Self-pity’s seed of wisdom comes in recognizing ones’ own part in creating problems – I find that solving difficult problems often requires changes in my own views or behaviors. Here too it is taken to an unhelpful extreme: by complaining, you reinforce the counterproductive view that you are not capable of solving the problem yourself.


Each of these anti-patterns does contain wisdom: all are based in recognition of a problem. Without recognition there can be no solution. But once you have recognition, it’s best to use strategies that are known to be helpful

So how do you get what you want? The first step is recognizing these anti-patterns in yourself, if they occur. It’s also helpful to recognize them in others so that ones’ team can name them in a non-judgmental way, and begin to learn healthy and constructive patterns of leadership.

Do take care of yourself.

In other words, stay rational. In terms of the Core Protocols, this means keeping the Core Commitments. To solve problems effectively, by yourself or with others, you need to be in a rational state of mind. If you can’t be rational, you won’t be able to be productive.  The Core Protocol that is relevant is Check Out: to remove yourself from situations if you notice that you or others are irrational, returning when you and others are rational.

It may seem odd that that the first road to getting what you want is to leave, but I and others like John Gottman have found that Checking Out – minimizing flooding – is an effective problem-solving strategy. Things that are easy to solve in a rational state of mind are hard or even impossible to solve when one or more people have their minds clouded by strong emotions. This is just part of being human, but it is one of the hardest roads to follow.

Do ask for help.

You are not alone. Often when faced with problems, people try to solve them alone.  One of the Core Commitments is, “Use teams to solve hard problems.” Problems that are hard for one person to solve might be easy for two.  Or it might require a few more – but simply by working with others often leads to quick resolution. This is true because other people have other viewpoints, other resources, and other emotional responses.
Friends holding hands

To ask someone for help, simply say, “Will you help me?” This is the clearest way to ask someone, since it recognizes that they may say no. The Ask For Help protocol has more details.

Do investigate yourself and other people.

Every successful problem solver starts with “I don’t know.” The next obvious step is to learn more. How do you do that? Investigate Protocol is good if you want to know lies with yourself, someone else, or if you simply don’t know where to start.

Often the solution to a problem can be found within yourself. Simply find someone, and ask them to help by investigating you as a detached but fascinated observer would – telling someone your problems can help you realize the right course of action. The Investigate Protocol explains how to do this.

If you think clues about the solution might lie in someone else, you can ask them for help and investigate them.

If you don’t know where to start, having someone investigate you is helpful because by telling the problem to others helps generate ideas. How many times have you asked someone for help, began telling them about it, and then realized the solution?

Do create new solutions.

The best way out of a problem is often to invent something new. This requires imagination and creativity. Simply use your natural talents until you come to the solution, or until you encounter another problem that is blocking you from solving your main problem. You can do this alone, or with a small group of people.

You can create even when you know you can’t create a good solution by yourself: once you have a proposed solution, even if it is unworkable, you can get other people to help improve it. It is much easier to improve an existing solution then create one to begin with.

Creating is the only one of these “Do”s that does not have a Protocol associated with it.

Do improve existing solutions.

It’s much easier to improve something than to create it. So what is the best way of improving a proposed solution? The Perfection Game Protocol provides a structured, non-violent way to give this feedback: First, you rate the work product from 1-10, 10 being best. This is a measure of how much improvement you think you can make, a 5 means you can double it, 3 means you can more than triple it, 1 means you can make it 10x better. If you can’t think of any improvement you must rate it a 10. Then you say what you like, and finish by giving concrete suggestions for what it will take to make it a 10.

You must limit yourself to positive statements that actually improve the work. In this way people can receive the feedback optimally, and then decide on their own what suggestions to use or discard. This is a non-violent technique since there is no criticism or negative statements.

Do listen deeply to other people.

Truly hearing someone else is often enough to solve intractable problems with other people. Listen Protocol provides a structured, non-violent way for two people to deeply understand each other. ListeningThis is done by having one party state their concerns, one sentence, idea, or feeling at a time. Then the other party repeats back what they said. In this way the speaker can know the listener truly understands what they are saying. You can use a coach to help both parties keep to the structure.

Often when the emotions behind a conflict are deeply understood by all involved, the solution to a conflict will become clear too.

Do make effective decisions.

Decide first, don’t discuss. This is because everyone may already agree with you, and if so, discussing wastes time and energy. If they don’t agree with you, when you decide you can find out exactly what is preventing you from getting what you want.

Discussion is a natural part of human society, and can be quite fun and fulfilling. In team behavior, however, discussion is an anti-pattern, because it does not lead toward action. If you want to achieve a goal (getting what you want) you need to get a group of people to move toward it.  Discussion does not do that. The way groups keep their actions aligned in the same direction is by making great decisions.

The Decider Protocol, and its companion, Resolution Protocol, provides a way for a small group (less than 7) people to make good decisions quickly. Why is speed important? Greatness is simply the abundance of goodness. If you can make good decisions quickly, you create an abundance of them. The Marine Warfighting Manual has this to say:

Time is a critical factor in effective decisionmaking—often the most important factor. A key part of effective decisionmaking is realizing how much decision time is available and making the most of that time. In general, whoever can make and implement decisions consistently faster gains a tremendous, often decisive advantage.


I have found these rules of thumb to be fast and effective ways to get what you want. Since getting what you want is a key leadership skill, mastering these techniques is a good way to increase your capabilities as a leader in all the realms of human life: self, family, friends, work, and society.

There are several points that I did not cover in this article. The first is how to get a group of people to want the same thing (shared vision). Another is, once they want the same thing, what is the fastest way to get them to practice the behaviors described in this article? I will cover these in a later article.

Thanks to Jim and Michele McCarthy for significant help improving this article. Thanks to Lena McCullough for helping with the pictures.


We believe we can make a difference.

We create legendary teams that call forth genius as needed.

We believe these legendary teams will make a significant positive difference in the world.

We believe legendary teams can create and implement technologies, businesses, and organizations that make the lives of billions of people significantly better.

We believe that joining a legendary team will transform a person’s life.

We believe these legendary teams will transform the world of work to something healing to people and the world.

We believe people can learn to wake up and see this is possible.

Our teams are fun, healthy, and high-performing.

Our teams use the best team technologies to achieve their results.

Our teams solve the world’s great problems effectively and without drama.

Being on our teams is an awakening, life-transforming experience.

Two years on one of our teams is better for your life than any university degree.

We train leaders who create great teams themselves.

Our teams create companies that people beg to become customers of.

Our teams create companies that investors line up to buy stock in.

Our teams are opportunities that smart, caring, creative, effective people consider their dream job.

Our teams are cherished by their communities for what they bring to their neighborhood and the world.

Our teams create companies that competitors respect, are challenged by, and look to for leadership in the market.

Our teams create companies famous for being the best in the industry, famous for their integrity and honesty, famous for the respect they have for their employees, famous for solving their customers’ most difficult problems.

I wrote this as an aspiration for myself and my teams. If you want to find out more about how to create teams like this, check out the essay Solving the Problem of Problems.

Ending Poverty With Software paper in Open Source Business Resource

My paper on Mifos was published today in the online journal Open Source Business Resource:

We believe that software and business are two key elements for solving poverty. First, we do not assert that software alone is enough to end poverty – poverty has many factors, and eradicating it will require many innovations. Rather, we assert that any solution to ending poverty will need software in order to reach all poor people in the time given. Second, we assert that business must play a role in the effort to eliminate poverty as an effective social technology for generating wealth. Eliminating poverty for 2 or 3 billion people is something charity cannot do…

Where software and business come together in the service of poverty is in the field of microfinance. Microfinance is the business of providing financial services to poor people.

Ending Poverty With Software article

The December issue of OSBR covers humanitarian Open Source software projects, there are articles about OpenMRS medical records system, Sahana disaster management system, humanitarian open hardware, and others.

Entrepreneur’s Top 10 Legal Mistakes (and how to correct them)

Here’s a short guide I wished I would have had when starting out as an entrepreneur. All these could be my #1 item, I’ve made all of them at one point or another or else been a principal in a company where the situation arose to my detriment. If I had to pick a top mistake, it would be:

7. Not having your own attorney.

Don’t expect venture capitalists (VCs) to look after your interests. When your company is ready to raise funds, the fund provider, usually a VC or two, will be represented by legal counsel. The VC will usually insist that the company hire a fancy law firm that has experience with corporate finance and securities. But who is representing the entrepreneur? Often, no one. You need your own independent legal counsel. You may be hesitant to hire an attorney because you do not want to kill the deal or seem like you are getting in the way. But a good attorney will look out for your interests in a way that does not hurt the company. The same is true if the company is going to be bought by another company.

One thing that that Gary doesn’t say about this is that when you are starting a company, and you have a personal attorney, use them. Run every legal agreement by them, even if you don’t think you need to or especially when other people are telling you not to. This practice may save you a lot of time, money, and trouble. See it as a cost of doing business – a personal attorney is your advocate and is there to help you understand the risks of legal situations.

The reason I put this as my #1 is that a good personal attorney can then teach you about the other 9 problems and help you avoid them.

(Top 10 Common Legal Mistakes Entrepreneurs Make – written by my great personal high-tech attorney, Gary Marshall.)

What We Look For In Founders

Paul Graham has a new, great short article on what Y Combinator looks for in founders. Here’s the summary:

  • Determination
  • Flexibility
  • Imagination
  • Naughtiness
  • Friendship

Note that these are also key characteristics of great teams! All the points are good, but I especially want to quote from the section Naughtiness, since it’s something you don’t see discussed very often:

Though the most successful founders are usually good people, they tend to have a piratical gleam in their eye. They’re not Goody Two-Shoes type good. Morally, they care about getting the big questions right, but not about observing proprieties. That’s why I’d use the word naughty rather than evil. They delight in breaking rules, but not rules that matter. This quality may be redundant though; it may be implied by imagination.

Sam Altman of Loopt is one of the most successful alumni, so we asked him what question we could put on the Y Combinator application that would help us discover more people like him. He said to ask about a time when they’d hacked something to their advantage—hacked in the sense of beating the system, not breaking into computers. It has become one of the questions we pay most attention to when judging applications.

I have written about D.A. Henderson’s Smallpox Eradication Team elsewhere, but want to underscore the naughtiness point here as it relates to teams. In his book Smallpox- the Death of a Disease: The Inside Story of Eradicating a Worldwide Killer Henderson says unequivocally that a willingness to break unhelpful rules was one of the main reasons that his team was able to succeed in its ambitious quest to eliminate the deadly smallpox disease from the Earth.

(Via Hacker News)

Team Greatness

I recently posted a new essay on team greatness:

Something is known about how people become individually great. Richard Hamming gave a famous talk on that subject, You and Your Research. While his talk was about the problem of individual greatness, he acknowledged that groups or teams have the potential to become great also. This essay is about how to reliably produce great teams.

Before we dive in, let’s talk about why reliably producing great teams is important. I will mention some problems in the world that are important to solve: ecological devastation, poverty, war, disease, and the meta-problem: the survival of our species. Just working harder is not going to solve these problems – people have been doing that for thousands of years without success.

If you look at the most difficult problems facing humanity, I think it is self-evident that if we would have an abundant number of geniuses working on these problems, they could be solved. If you study the work of applied genius throughout history, you can see this is true.

So why haven’t all the problems been solved already? This is the Problem of Problems.

Read more here: Solving the Problem of Problems.

Software For Your Head book available online

The Software For Your Head book by Jim and Michele McCarthy is now available on the Live In Greatness website! This is the book that got me started on the Core Protocols. For those that haven’t read it, here’s a bit about it:

At least once in their lives, most people experience the incomparable thrill of being part of a great team effort. Members of successful teams often feel a unity of purpose, powerful passion and inspiration, and a strong sense of accomplishment. People who have been on a great team know that the difference between being on a team with a shared vision and being on a team without one is the the difference between joy and misery.

After successful careers leading software development teams at Microsoft and elsewhere, Jim and Michele McCarthy set out to discover a set of repeatable group behaviors that would always lead to a state of shared vision for any team. The result was a practical, communicable, and reliable process that could be used to create the best possible team every time it was applied.

Software For Your Head is the first publication of the most significant results of the authors’ unprecedented five-year investigation into the dynamics of contemporary teams. this book will give any team the know-how it needs to create its own compelling shared vision.

I also put up the Core Lexicon from the book in HTML format.

Ending Poverty With Software

Matthew Russell recently interviewed me about Mifos for the PayPal X Developer Network. This came about because Adam Monsen, Van Mittal-Henkle, and I gave a talk called “Ending Poverty with Software” at OSCON 2010.

I don’t believe that only software can end poverty. But if we want to reach the 2-3 billion people in poverty, we definitely need software.

uIP TCP/IP stack and ZG2100 wireless drivers for the Leaf Labs Maple!

Maple and WiShield running the WebServer demoPerry Hung just ported the AsyncLabs WiShield 2.0 (ZG2100) drivers to the Leaf Labs Maple board!

Here’s picture of the two boards running the WiShield WebServer demo. You can see the wireless connection light is on.

Maple is a sweet new Arduino-like physical computing platform. It’s got analog and digital in and out like the 16MHz, 8-bit Arduino, but is based on a faster, 72Mhz, 32-bit ARM Cortex M3 processor from ST Microelectronics. It’s about $50. The WiShield is about $50 too. The ZG2100 is only about $30, so it is probably possible to build a lower-cost combined board.

HTTP is the new device driver! A new age of iPad and iPhone compatible, Arduino-like devices are upon us! Yay!

P.S. If you want to check out the code yourself, see
Perry’s GitHub repository
. Check out the wishield-dev branch like this:

git clone -b wishield-dev git://

Build from the command line like this:

$ make flash
$ make install