By Scott Berkun, November 2004

Many people spend their entire careers waiting for a chance to work on a version 1.0 project. When it happens, they’re so thrilled to work on the beginning of something that lessons learned from other projects are forgotten. The terms groundbreaking, breakthrough, radical and innovative are thrown around enough that many are convinced the current project is different from all others. Somehow in the belief that they’re doing breakthrough work, they allow themselves to believe that many of the basic lessons from other projects don’t apply anymore. As an antidote to the common management failures of v1 efforts, this essay explores the common mistakes with new efforts, and offers advice on how to avoid them.

You’re always improving on something else

Human beings don’t do very many things. And the things that we do, we’ve been doing for a very long time. A new cell phone can improve the ability for two people to communicate, but it can not invent communication. A new automated accounting website can eliminate tedium or improve productivity, but it can’t invent accounting, or automation. This doesn’t mean that radical improvements aren’t possible: it just frames them as improvements, not divine invention. The idea of innovation is best seen as making improvements in solving a problem for people, rather than as changing the fundamental nature of human behavior.

Always look carefully at the project vision and charter, and carefully separate out the useful pursuit of problem solving in the world, from the fantasyland proclamations of reinventing how the world works. I admit the difference is entirely a matter of perspective: I’m just suggesting stepping back away from the project to get some (perspective), is well advised before you commit to the pursuit of an idea for months or years..

Pragmatically speaking, the reason why this separation is important is that the seeds of successful version 1.0 projects come from examining the existing ways people do things. Dan Bricklin’s ideas for the first spreadsheet application VisiCalc came to him while thinking about, and using, a standard calculator. The Palm Pilot examined paper organizers and tried to expand on what they did well. The Wright brothers carefully watched birds fly before they built their first planes. Many of the great innovations in technology had direct and specific connections to something already in existence in the world, combined with a desire to make it significantly better.

So innovation does not require starting from scratch. This is good, because you can’t start from scratch: the universe has been here for awhile. In fact, successful innovation often happens simply because a curious person paid careful attention to how something in the world works. And once they really understood how people use that thing, they could see what was both good and bad about its value to those people. With that understanding, a creator can apply their imagination towards new ideas that eliminate the bad and expand on, or leap-frog, the good. Technical brilliance may be the only way to realize that imagination, but it’s the ability to generate or recognize those meaningful ideas that drives the best kinds of innovation.

If you agree with this, it demands that any version 1.0 project invests energy in understanding what will be improved on. How are people really using that old accounting system or HR website? (Don’t assume. Don’t guess. Go watch them. Talk to them. Actually listen to them). There may be common knowledge for what sucks about the old system, the old way, but what’s good about it? Someone has to spend the time asking questions, tenaciously and patiently, seeking out answers. If there is currently no technological based way to do what your project will do, look at non-technological ways. How do people do it without computers? What’s good about how they do it? Bad? What aspects can be improved by technology? What aspects will be made worse by technology if you’re not careful?

Version 1.0 may be the first instance of a new way to do something, but it doesn’t invalidate lessons learned from all of the other ways that currently exist for how to do that thing. In fact, the more a version 1.0 can leverage from the technology and non-technological lessons of other solutions to the same problems, the stronger that version 1.0 will be. Smart managers connect with the past and make their version 1.0 the next step of all that has already been learned.

The hubris of v 1.0 psychology

The reason why many project teams ignore the past is belief in uniqueness. In order to get the project started leaders and managers had to convince executives, VC, programmers and designers how new the core ideas were, or how dramatically better the resulting product will be. Slide decks, elevator pitches, and one pagers, were created to convince others that there was a new way to look at the world (or at least the part of the world relevant to the project). So when the project launches in earnest, that psychology doesn’t go away. It can’t. The team is using that belief system to help get them to show up at work every day (and stay late every night). No matter how ridiculous the core ideas are, once a team has bought into them, they become leverage for managers and individual to use for motivation.

Side note: For this reason there are parallels between version 1.0 efforts and political or religious movements. All three employ methods to bring groups of people together, develop a shared belief system, and get them to work towards shared goals. The challenges leaders face are similar as well: how do you bring new members into this mindset? How do you grow your base of influence? How do you sell outsiders on the belief system? But this is a subject for another essay.

Often version 1.0 brings with it new vocabulary for things that are already well named. Instead of database, the lingo becomes “high speed query server” Instead of shopping cart, it becomes “customer conversion sequence”. This often happens naturally. It’s the spill-over of that initial world view (this project will change the world) applied to the mundane and tedious aspects of engineering things (how can a shopping cart change the world?). Everyone wants to believe that they are working on something different and innovative, since that’s what they’ve been sold on, and when forced to choose between a silly new name, and confronting gaps in the mythology of the project, most people will choose silly new names for things. Often the silly new names are conceived and promoted by team leaders: and it’s not for evil reasons. They themselves believe in the mythology, or at least see the value of the mythology towards motivating and leading people in the organization.

This hubris is the primary cause of rejection of lessons from past projects. Instead of looking honestly at the world for inspiration and understanding, project v 1.0 hubris suggests that the invented, no matter how ridiculous, is more valuable than the borrowed or the learned. Not Invented here (NIH) syndrome, where all ideas of distant lineage are rejected, is a sister disease that may also afflict version 1 projects. The absurdity of NIH is that most things are not invented wherever you are: buildings, offices, telephones, fax machines, electricity, TCP/IP, etc. are all critical to the project, but were invented in other places, by other people. It’s strange that some ideas are rejected solely because of their origins, but not others. For those that are insecure about their own ideas, NIH is an easy way to level the playing field (as well as to waste lots of time).

So the wise leader of a version 1.0 project has to separate out the positive aspects of faith in the ideas of the project, from the negative and limiting assumptions that most people will take with them. “Yes, the ideas are groundbreaking. But no, don’t ignore the current state of the world. Don’t ignore the previous website/software/OS. In fact go out of your way to learn from the past and current state of the world, since that will enhance our ability to build something good.” This approach requires more intelligence, maturity and leadership skill, but has greater odds of success for the project, and sanity for the team. And for the truly bold, leaders should allow for the goals and core ideas to change based on what the team learns from the world. When the map and the landscape don’t match, the wise leader follows the landscape. When a programmer explains why a core assumption for the project is inaccurate, don’t reject the explanation, rebuild the assumptions.

The good visionary vs. the good manager

Good visionaries are rare. Good managers are rare. Good managers who are also visionaries are extremely rare. Worse, unlike pro football quarterbacks, there are no public statistics we can examine for how well our own managers performed on past projects (Though it’s fun to imagine what statistics we would want to keep). Many visionaries believe they are good managers, and vice versa, but the shortage of these skills suggests that most of them are wrong (Sorry, but this probably includes you).

The irreverent rule breaker, big thinker, and authority challenger is rarely the best person to track schedules, write specifications, or ensure that paychecks arrive on time. The kinds of personalities that lead to achievement in these things differ significantly. There are a handful of people in every organization that have enough personality traits and skills to cover both well, but most people don’t. And even those rare souls that are good at both still have gaps: everyone has some things they are better at than at others (or more cynically, everyone sucks at something, if not many things).

In start-ups or small teams, you don’t get much choice: the team leader is the leader and the freedom from large organizational hierarchy brings with it the increased dependence on the few managers you have (and/or increased self-reliance). However the wise small team leader acknowledges their strengths and weaknesses, and uses this awareness to work in support of the version 1.0 project, rather than against it. For the visionary leader, but weak manager, some management tasks can be delegated to the team, or handled communally. If there is a weekly meeting that needs to be organized, it doesn’t have to be the team leader that sets the agenda and keeps the meeting on track. It can be a job for an experienced person, or a role that’s rotated to a different person each week. For managing staff, a process and schedule should be adopted that forces the visionary to provide at least minimal personal support for individuals (weekly one-on-one discussions, focused on the individual’s issues, not the manager’s). Even if the visionary isn’t great at performing these duties, it’s his job to make sure they’re done at a minimal level of competence. If there’s any hope of him or her getting better at it, it starts with doing it regularly and paying attention to the feedback they receive for it.

Alternatively, for the strong manager who lacks visionary and artistic drive, passion can be cultivated and harvested in others. Look around the team: who gets excited? Who is articulate about what excites them? What opportunities can the manager make to give the passionate a platform for expressing it, shaping it, and sharing it with the team? The project vision, the core ideas that define the goals for the work, can be drafted and developed by someone other than the manager. It can be done as a working group, with 4 or 5 people working together to generate and refine the project direction, with the manager taking the role of executor and leader, and delegating the idea generation and big thinking work.

In all situations there are just two secrets. 1) Work to discover and admit to your weaknesses as a visionary or manager. 2) Invest energy in healthy ways to compensate for those weaknesses either by delegating, developing skills (training), or hiring carefully in the future.

Avoidable Chaos: goals and solutions

Doing something fast and new always involves chaos. There are too many new situations that are being dealt with simultaneously for things to go smoothly. Often there are muti-dimensional changes: people, code, organization, direction, management, tools. And the way they interact with each other is too complex to predict. The more aggressive the project, the more decisions that will be made at the same time, and the higher the odds of things being chaotic and difficult to control. (Some find this fun: those are the people that want to work in start-up environments. Some find this a nightmare: those are the people that want to work on large well established teams).

But some of the chaos is avoidable. Finding the avoidable chaos and eliminating it is the work of the smart manager. Lesser managers throw up their hands in the face of chaos, and allow all sorts of stupid things to happen simply because it’s a version one effort. They allow lots of dumb decisions to get swept under the “version 1.0” rug. As much as new efforts need to be quick and flexible, they don’t need to be stupid or idiotic. In fact, the more dynamic a project team needs to be, the more work leaders need to be doing to make sure the team is set up to work smart. Someone has to carefully separate avoidable and destructive chaos, from the desirable and constructive kind. Not all chaos can be separated in this way, but some of it can.

The simplest observation to make about finding avoidable chaos is separating out the pursuit of goals from the pursuit of solutions. If the team is churning on direction (“Lets go west, no wait.. go south.. no wait..”), all work done by the team is vulnerable to being wasted. However if the team has clarity on the problems to be solved, and is churning on solutions, the risks to any individual’s efforts are much smaller (“Go northwest, no wait, go northwest-by-north”).

Even if things are churning at a high level, team leaders have to constantly refresh the team’s understanding of the most recent success criteria. If it changes daily, it should be written down and communicated to the team daily. Management defines the heartbeat of the team: if the pace of change is fast, then those management beats need to be fast to keep the team working at the same rhythm (and in the same direction). If this is done, it’s ensured that any daily chaos and churn will be serving the same central ideas, and that a shared framework across the project will exist for sub-teams or proactive individuals to cultivate local success criteria, based on the project wide ones. Even if management hasn’t resolved an issue yet, clarifying for the team that:

• The issue exists
• Someone is working on the issue
• Who that person is, so folks can ask him/her questions
• When it will be resolved (never may be an acceptable answer: it will free people from waiting for something that will never happen).

Assigning responsibility for specific issues always has positive effects. It sequester’s chunks of chaos, gives them names, and places a person on point for responding to any complaints or suggestions that arise. One of the most common things swept under the v 1.0 rug is the inability for a manager to delegate: if all issues point back to the same person, no wonder it’s difficult and frustrating for anything to get done.

The vision goes beyond v1.0

There is great pressure on leaders to deliver in version 1.0. So many promises are often made to simply get a new project off the ground, that team leaders quickly find themselves in impossible situations. The schedule and the resources don’t allow for half of what executives or investors want to see when the work is done. Sadly, the willingness of programmers to abandon their lives and commit all their waking ours to the project is rarely the solution (Thought it might be necessary to fulfill whatever the solution is).

The problem is in expecting a single effort to fulfill a vision. A single battle rarely wins a war, and a single release rarely wins a market, transforms an industry, or makes a division or start-up financially viable. Instead it takes a sequence of well executed developments towards the same high level vision, the same high level goal. When too much pressure is placed on a single first release, there’s rarely anyone still sane enough to pick up the flag and lead the charge for the inevitable version 2.0. As much as version 1.0 projects can be sprints, whoever is defining the strategy should be thinking of it as a relay race, a sequence of sprints, and not a single solo effort.

This means that wise management expands the vision out across multiple releases, looking at least one effort past the current one. It might only be a sketch, or an outline, but the team should know that there is a strategy that extends beyond the short term drama. It should be clear in the minds of anyone in management that the fulfillment of the vision will come only with strong solid and continual progress: not one wave of work (Though there are rare exceptions). For the start-up CEO or team leader, thinking this far ahead may be impossible. There may be 3 or 4 scenarios that are equally probable for what comes next. But if it were me, I’d tell my team what they were. Not every day, or every hour, but I’d want to periodically provide status about where the ship is headed after we arrive at the current destination. If I have a reasonable strategy for facing uncertainty, and I share it, they’ll tend to follow.

As a simple example: compatibility and consistency are generally thrown out the window during the race to version 1.0: yet any experienced leader knows these things are the first things demanded in version 2.0. If expectations (at least internally to the team) can be set early on, the 1.0 effort will have clearer goals, and spend more time delivering than debating. The team will also have a sense for what the future will hold after version 1.0 is out in the world.

A smart organization centers the goals of version 1.0 on validating key assumptions for the team and for management, (and possibly for the industry or investors). V 1.0 should deliver on clear improvements on the most important customer scenarios, establish core technological progress, and provide a foundation for future efforts. Management needs to be eloquent and precise about what those scenarios and supporting technologies are, and what improvements on them truly mean.