Making It Real: The Smartest, Fastest, and Easiest Way to Build Organizations 2.0

I think we can agree that, over time, we have come to build exceptionally complex organizations, full of departments and hierarchies, full of instructions and rules, of very complex business processes and decision-making. In the current scenario, marked by accelerated change, competitiveness and the constant flow of information, our organizations have become inefficient, slow, bureaucratic and, what is worse, deathly boring, capable of killing the passion and creativity of the most fervent of our collaborators.

The good news is that Web 2.0 is showing us every day new ways to deal with these limits, characteristic of traditional organizations: from the harnessing of collective intelligence to create an open operating system like Linux or an encyclopedia of free content that we can all edit like Wikipedia, to the construction of social networks like Myspace, Xing or Facebook, where hundreds of millions of people can share, create and collaborate in global communities that just two years ago did not even exist. Following the guidelines of these and other innovative experiences, when creating together with
Agustín Cuenca
and Xavier Noria, our own company Web 2.0 – ASPgems – we chose as a frame of reference

the model of 37Signals, an agile and innovative company that has become a world leader in the development of Web 2.0 applications. 37Signals has developed a whole philosophy that it has called “Getting Real”. From our own experience, can be considered as the smartest, fastest and easiest way to build Organizations 2.0.

“Making It Real” as a paradigm

The central idea of the “Getting Real” philosophy for application design and business problem solving is that, instead of spending a lot of time “representing” the real through specifications, mockups, diagrams, etc., we must “make it happen”, creating the first version of our solution as soon as possible. Then we can improve it based on the interaction with reality (with real customers and users). The paradigm of “Getting Real” means, in short, less complexity in design and less of everything that is not essential. Practice teaches us that most of what we think is essential, in reality is not.

This philosophy means accepting that in a complex world like today’s, where time is the fundamental variable, less is better than more; that it is better to consider limitations (time, resources and budget) as real allies that help us build simple and practical things, instead of assuming them as enemies, and lamenting how well everything would go without limitations. It means abandoning forecasts associated with hypothetical problems to concentrate on real and current problems; it means limiting the aspirations of greater functionality to build limited, but highly efficient solutions; it means, in short, prioritizing design over theoretical architecture, thus bringing our products and solutions closer to the real use that our customers and users will make of them as soon as possible.

“Less is more” as an organizational culture

A week ago we celebrated the second anniversary of ASPgems and, reflecting on the typical messages and discourses of these occasions, the key question arose: What makes us different as an organization 2.0? What, after these two years, are our values and our organizational culture? What makes our products and services different? I have come to the conclusion that beyond the human team – highly qualified professionals who have shown their capacity and responsibility in previous experiences – what truly differentiates, the real key is, without a doubt, in our commitment to
“Less is more”
as a value and organizational culture. Our commitment to eliminate the superfluous to keep what is truly essential. It is, after all, a matter of priorities. You have to choose. It is about defining what the “heart” of your value proposition is, and building an agile and flexible organization on it; it is about keeping what really adds value to your customers, and eliminating everything that is excessive. That is why our software products, unlike others, only include what users always use, instead of everything that someone has ever used. For us this is essential, since our products are dedicated to SMEs and freelancers, who need easy-to-use, low-cost tools in “service on the network” mode. The use of agile technologies such as
Ruby on Rails
, which allow agile and flexible development, has been a perfect complement to make our motto a reality: “Less is more”. You can see a good example of what I am talking about in our FACTURAGem invoicing solution. As you can see, the application is very clear and easy to use. It knowingly and intentionally does fewer things than other invoicing solutions on the market, but it does the essentials for an SME or freelancer.

The “Getting Real” philosophy applied to Organizations 2.0

Although the “Getting Real” philosophy was born in the highly innovative environment of technology companies, I believe that its reach goes much further. Some of its principles can serve as a guide in the exploration of new forms of leadership for organizations. These are the ones that have been enormously valid in our own entrepreneurial experience:

• Experiment with reality. Avoid detours, just “Make It Happen.” Don’t waste time simulating reality. Don’t spend your time trying to document reality with detail diagrams and functional specifications. Create it and experiment with it. Launch something that really works as fast as you can. It’s the best way to build momentum. It’s okay to build fewer things, skip the details, and take shortcuts in the process as long as it allows us to get the project up and running faster.

• Cultivate simplicity as a value. It may be better to simplify a process rather than train people to deal with complexity. Over time, organizations become accustomed to complexity. They don’t notice it, and they tend to increase it. In daily practice, not everyone feels capable of coming up with creative ideas; but everyone can point to something that could be done in a much simpler way. In addition, simplicity makes it possible for new people to join the organization more quickly, and to be productive in less time. If we come to believe that simplicity is as real and important as cost, then we can make more efforts to achieve simplicity

• Remember that “less is more”. In real life, when it comes to getting things done, less is more. You need to focus on the essentials and reject the superfluous: fewer people in teams, fewer instructions, less paperwork, fewer hierarchies, fewer forecasts, and fewer meetings. You need to do only what is truly central and important to your business and do it well. Less thus becomes less change cost, less margin for error, less support needs, fewer useless explanations. Less means simplicity, clarity, and a job well done.

• Create agile organizations. This philosophy has to do with agile and transparent organizations; small, fast and flexible, open to change and innovation. Organizations with less paperwork, less mass, less fear and, in return, more flexibility, more changes and, definitely, more freedom.

• Avoid the “Passion Killers”. Hire happy people, with passion for their profession. Look for good students: people who are curious and eager to learn. An average professional who is motivated and satisfied with what they do is preferable to a disgruntled and frustrated “guru”.

• Work through iterations. All decisions are temporary. You’ll come back to them again. So don’t stop: decide and move on. Don’t obsess over getting everything right the first time—it’s impossible. Take the pressure off. Let the project grow and speak to you, take shape, and evolve. As you progress through the iterative process, you’ll get to know the project and its circumstances better, and you’ll have input from your collaborators as well. This will allow you to make better-informed decisions. Don’t forget to celebrate the small successes that come with each interaction, and share the lessons learned.

• Stick to the deadline and budget; adjust the scope. In the development of a project, we handle three fundamental variables: the deadline, the budget and the scope. In an environment like the current one, highly competitive and with accelerated changes, time is the key variable. The solution is to adjust the final scope of the project well. In other words, you have to establish the priorities well to carry out the fundamental part – the heart – respecting the deadline and the budget. Projects years ahead are nothing more than a pure fantasy, an entelechy that never takes shape as planned.

• Develop the “heart” of your idea first. Stick to what is truly essential. Good ideas can be narrowed down; not-so-good ideas, on the other hand, are difficult to formulate. Follow the recommendations of “Getting Real”: take what you think the project should be and cut it in half. Keep cutting objectives to keep the basics. Break the result in half again: you already have the essentials. That is the “heart” of your idea.

• Build small and agile teams. Metcalfe’s Law has a corollary that explains the need for small teams well: the efficiency of the team is inversely proportional to the square of the number of members. In other words, the chances of communication problems increase exponentially when the number of members increases. A multidisciplinary team of only 3-5 people is the optimal format to develop a project in its initial phase.

• Avoid the temptation to grow up. Not every company is destined to have thousands of employees, or to reach a billion dollars in market capitalization. Some companies should consist of only 10 people, 5 people, or even just one. Finding the natural size of your company should be a triumph, not a capitulation. Conventional wisdom has assumed that companies must always be growing, and that they are dying. On many occasions, this dichotomy leads perfectly viable companies to an untimely and unnecessary death in the pursuit of continuous growth.

• Shorten the time, chop up the problems until you can digest them. Chop up the time available. Chop up the problems as well. Keep chopping up the deadlines until you get smaller pieces. Instead of a 12-week project, do 12 1-week projects: you’ll gain motivation and effectiveness. Continue to break the problems into smaller and smaller pieces until you’re able to digest them.

• Test your ideas in real conditions, with real customers and in real markets. Listen and improve. Always remember: you are developing a real project, so you have to test it in real conditions. Reflections in limbo, or laboratory tests, are useless. Test your service or product. Test with real users in real conditions. Don’t look for substitutes: they don’t exist. Work with real data. Get authentic feedback and, most importantly: make improvements based on the information you’ve obtained. You owe it to your users.

Don’t let the “legacy” annihilate your dream

It is obvious that many of these principles are only applicable when we talk about creating new organizations, Web 2.0 companies that operate globally with networked business models and products and services marketed through the Internet. It could not be otherwise since, as I pointed out in the introduction, the “Getting Real” philosophy comes from the world of agile software development. But it is precisely these “digital native” organizations that best allow us to explore the new paradigms of Leadership 2.0, and the ones that best expose the paradoxes of industrial organizations when it comes to responding to the challenges of the Age of Collaboration. That these ideas come from the world of software development is not surprising. I remember an occasion when I argued to a head of development that he was taking a long time to solve a seemingly simple but business-critical problem. He, after exhausting all kinds of apologies, imaginable and unimaginable, and seeing that he could not convince me, resorted to a phrase that I have not forgotten, and that I think is particularly valid when we are faced with profound changes in our organizations:

“God created the world in seven days because he had no installed base.” That is, he was able to do so because he did not have to take into account the legacy of interests of a previous world. The message is clear: when the world to come is very different from the previous one, it is better to create from nothing.

*You can see the content of this post summarized in the following presentation: