The Institutional Innovation Manifesto

Here's someone who says what I've been thinking, and more:

The Institutional Innovation Manifesto - Umair Haque - Harvard Business Review: "Whoever does reinvent the job might have finally built a company that's so relentlessly innovative, so fully engaged, so unshakably persevering that it reduces pretty much everyone else to a distant second place."

He talks about numerous other things that need changing, including the corporation and the board of directors (these, apparently, are just as bad as they seem from the outside).

It's very helpful to read others who are on the same page -- for one thing, it keeps me from thinking I'm crazy. Need to figure out a way to get us all together at a conference.

Formulas: "Hard to Find" doesn't mean "Impossible"

One dichotomy I've seen in the management world is "science" vs. "art." The science camp, which I and numerous authors have roundly criticized, look for the magic formula: do these things, turn the crank, and get perfect management. At this point, we've had over a hundred years of idiocy passing as science, peppered with the occasional insight based on true science; insights which are generally ignored. This produces the "art" camp as a reaction, asserting that each case is different so no formula is possible.

As someone who has dabbled in art and creativity most of my life, I am drawn to seeing management as art. And yet I've had at least two experiences which have shown me that, even when art is involved, it is possible to figure out rules or guidelines that make things work better.

Experience 1: Coauthoring

My first experience is coauthoring books. I've had two or three books (depending on how you count) published with coauthors, and a significantly larger number of projects that failed for various reasons. The failures tended to be messier, more dramatic and more unpleasant towards the beginning of my writing career. Some failures are simply because the coauthor had some kind of life change. The worst ones came through  what I'll call "artistic disagreements" -- disconnections in vision about what we were doing or how we were going about it.

My father -- a sole proprietor who was always the boss -- argued on several occasions that I just shouldn't work with anyone, that it was too much trouble. In the worst of times, this idea sounded pretty good. However, the benefits and leverage of working with others continued to attract me, and it also felt like a puzzle that itched to be solved.

The solution came from Gerald Weinberg, who has successfully coauthored some 50 books and thus navigated these treacherous waters enough times to figure it out. His formula boils down to three points:

1. No Contract Before the Book is Done. The agreement must be between the two of you, and you must both know that either one can walk away. For some reason, when a third-party publisher contract is added to the picture (along with publisher schedules and expectations), it destroys the delicate balance between the authors and often causes strife. If it's just a book that we are working on together, and there's nothing forcing us to finish it, then we do it because we want to.

2. Everyone Works on Each Chapter. The work is not divided. This prevents accidentally overloading one author with too much, and it ensures that the writing style remains consistent.

3. If it Stops Working, We Walk Away. Note that points one and two have the effect of encouraging the participants to put down the project, using the "fail early" philosophy (another example: After the one-month training period, Zappos offers employees a 2K$ bonus to quit). For example, "Everybody works on each chapter" forces you to interact, and if it's not working for someone you find out early. When Weinberg says "walk away," he means that the project is put in the dumpster and nobody gets anything from it.

Of course, this formula isn't perfect and we might discover a new point to add in the future. But in my experience it's very effective and tends to avert many of the problems involved in coauthoring. The remainder can be relegated to "art."

That's an important thing to note, that when things get messy the solution is typically a combination of science (producing rules) and art (knowing when to fudge the rules and adapt a new solution).

Experience 2: Theatre

I currently have the lead in the Crested Butte Mountain Theatre production of Moon Over Buffalo (which explains why I haven't been posting much lately). This is my ninth or tenth production, and in the early ones I was noticing how much a play is like a computer program; lately I've been seeing the similarities to business -- theatre groups are even referred to as "companies."

So I've done this enough times to learn the process, and to see what works and what doesn't enough to form guidelines. I'll also note similarities to business.

1. The Team. You've got to have a team that's good enough; this typically means a certain number of experienced actors that know the drill and can carry and coach the inexperienced actors. Most of the guidelines for team management apply here, including the possibilities of getting a member who can poison the process or one that is a bad fit (typically, someone uninspired).

There seems to be an ongoing argument regarding startup teams; some say that the team doesn't have to gel and work well together. I believe the team is critical, especially since (in a startup) it's likely that you'll need to change what you're creating, and a gelled team will make that transition much more successfully than a team with strife. In the less-difficult environment of a stable company, a team still faces numerous challenges and will survive them far better if people enjoy being part of the team.

2. The Play. You've got to create a decent product. A great team can only do so much to compensate for a badly-written play -- however, a great team will not want to participate in such a play. Indeed, just as in Experience 1 above, these factors are synergistic and don't stand alone.

3. The Schedule. A great team and a great play can't be produced properly if you don't allow enough time. There are certain immutables: memorization seems to depend mostly on sleep cycles, for example. It's hard to really emote until you have internalized your lines and blocking (how you move around on the stage). As much as a manager might want to accelerate the schedule, certain things take time to do right. The "Iron Triangle" (features, schedule, cost) is really more of a "plasticene triangle built over iron;" you can sometimes modify one aspect to change another, but there are also hard limits -- throwing more money at a project, for example, can only speed it up so much.

These "formulas" are actually very strong guidelines that require a mix of art when they don't quite fit. They weren't easy to discover, and at times it can seem impossible to discover them; mostly because they are not quite science, but rather a kind of squishy science. Management clearly suffers from being a squishy science: it allows hundreds of charlatans to make things up (and cause tremendous suffering in the process) and it makes it a daunting task for someone like myself who tries to sort it out. I have to keep reminding myself that it's not supposed to be easy, that this is "my personal Everest."

Customer Focus vs. Employee Focus

I was recently explaining the Reinventing-Business venture to some folks and the subject of Zappos came up -- in particular, the Zappos mission: "Provide the best customer service possible."

Contrast this with the argument I'm trying to make: that a company should focus first and foremost on the happiness of its employees (and all good things will follow from that). Indeed, Zappos does emphasize employee happiness. But that's part of the culture, not the mission statement.

I don't think this is an unimportant distinction. The most effective mission statements choose one thing, and the ineffective (non-memorable) ones try for a smorgasbord. I think you might only get one choice.

If that's true, it might seem like the difference between customer and employee is small; certainly either one is a far better choice than "maximize shareholder value," which has caused no end of grief by perfectly disconnecting the owners from anything except a monetary interest in the company.

The reason it's important is that it changes the perspective, and that changes how you make decisions. From the customer perspective, a company is a collection of products and services. From the employee perspective, a company is a collection of teams (which, in turn, create those products and services).

With a customer perspective, you make decisions around products/services. It would be acceptable, for example, to break up a team and distribute its members among different products or services. But with an  employee perspective, you make decisions around teams, and it would not be acceptable to break up a good team. A seemingly small change in focus between customers and employees produces radically different results in decision making.

I'm certainly speculating when I assert than an employee focus will produce a stronger company, and that from that focus will come far better products and services and profitability. However, we have labored under the myth for far too long that a shareholder focus will accomplish anything good. It's time for some new experiments.

Nature vs. Nurture

Today I got a "lightning visit" (about 30 minutes) from someone I know through the Java Posse Roundup; he and 6 of his friends were touring around the Colorado mountains. Every one of them had grown up in Israel, then come to the US and gotten involved in different startups. When I commented on the pattern, one of them pointed me to a book called Startup Nation; the entire country of Israel is a kind of startup and it has the highest per-capita number of startups. Another said that everyone in the country is a manager because they have to be. Also, the Jewish religious tradition is one of questioning everything rather than believing by rote all the religious texts -- with that kind of foundation it seems like you'd be more likely to start something yourself instead of accepting the conditions of existing businesses. (Side questions: in the end, apparently, you have to accept the Torah as it is; there isn't an option to rewrite it. So how many people, after being taught to question, end up decamping? And what would happen if you created a religion/philosophy that not only taught you to question, but also to rewrite? What kind of culture, and in particular business culture, would that produce?).

The culture you grow up in seems to have a remarkable impact on what you end up doing. My father was an independent businessman (building contractor) so it seemed like the normal thing for me to start my own business, as did my brother -- but neither of us thought in terms of startups. For me, it's taken a long time for me to see the value of giving up the control of self-employment, to see the benefits of working in a team. That came from talking to people at conferences and from my own reading and research ... and even then, only after my mind has been forced open to the idea. I wonder what the children of silicon valley will begin doing as they come of age.

During the conversation, it occurred to me that a good conference might be something that helps incubate ideas about startups and shares experiences between those who have created startups (both successful and -- a bigger source of information -- failures) and those who are thinking about it. This could create a group with a "startup culture."

Maximized Profits Are Killing Us

Physically and spiritually.

Change your perspective.

We need a new story.

Conference

Last week's conference went well. There were 8 of us this year, which sounds small but last year we were able to fit everyone in a single car -- convenient and intimate, but I always prefer the energy that comes from larger groups. Attendees this year succeeded in convincing me to persist, pointing out that not only are travel budgets restricted, but companies have resisted hiring people ... which means those remaining must take up the slack, work longer hours and spend less time developing themselves (we've seen this cycle before; when things turn up again, less-enlightened companies will start losing employees before they begrudgingly begin spending on employee development).

With small numbers, I didn't rent the hall this time (nor did I charge for the event). Instead, we met at a coffee shop for breakfast and the morning discussion, then went for a hike, had lunch and a break, then met at a different bookstore/coffee shop for the afternoon discussion. Although restaurants were a possibility for dinner, we ended up just barbecuing at my house each night -- this allowed for easier and more casual conversation.

The first morning I passed out post-it notes for people to write topic ideas, similar to a traditional open-spaces conference but in this case it was just a way to collect ideas, which I then wrote into a Google doc that people at the conference could modify. You can see the results here. We didn't talk about everything on the list, and we had other discussions that we didn't first put on the list, but it gives you an idea.

Although everyone who attended came from the programmery/enterprisey crowd, there were a fair number of reinventing-business topics that came up; not surprising since we continue to discover that the issues of business can easily overpower all the good things you can accomplish with the choice of programming language and agile methods.

One person, a long-time attendee at the enterprise architecture summit who has effectively fallen into management consulting, expressed some dismay that I wasn't attempting to reform existing companies (and thus coming up with useful techniques for doing so, which would be helpful in consulting). From my own (financial) standpoint, that would certainly be attractive, but right now I don't see how to do it, especially since the most compelling solution I've reached for creating a happiness-based organization requires removing the power hierarchies. There's just no way to sell that to the target audience (the very people who would be giving up their power), so currently the only solution is to create new companies with employee-happiness foundations.

I always enjoy these kinds of lets-get-together-and-learn events and want to create new ones, only partly because they have the possibility of (eventually) supporting my endeavors on this blog. The bigger reason is the energy and motivation they produce.

What Is A Startup, Really?

I continue to get a lot of good value from Stanford's Entrepreneurship Corner. Recently I listened to Eric Ries on Evangelizing for the Lean Startup. This is full of good stories and interesting ideas, but the concept that really changed my thinking was about the reason for the existence of the startup.

Ries makes a fascinating argument asserting that the goal of a startup is to find the right product. This flies in the face of traditional thinking, which says that you figure out the product you're going to make before you begin. Then you write your business plan around the product idea, raise money using the business plan, etc. In programming terms, this approach to startups would be called "waterfall," since you are supposed to know everything at each step.

Instead, Ries says that you don't know up front the product you will ultimately create. You start out thinking you know, and heading in that direction, but a fatal flaw that kills startups is not paying attention when you discover your original product isn't what the market wants. If you blindly cling to your original plan, you'll fail.

However, if you "pivot," as Ries calls it, and change products based on what you have learned, then you move closer to finding a product that customers actually want (instead of what you just imagined they wanted). In fact, this learning/changing process is so important that Ries says startups typically don't optimize the right thing. They typically optimize as if they were an established business, but what a startup really needs to optimize is their "cycle time," the time that it takes to get through an iteration of product development. This is essential because after each iteration you can find out whether customers want your product, and if not you can change. Because the "burn rate" through your initial cash is one of the most critical factors for a startup, the faster you can iterate, the greater your chances are for success.

Notice how this changes the perspective on a startup. For one thing, the traditional business plan becomes questionable. As Ries says, you can be making progress implementing your plan while driving the company into the ground -- the business plan (as others have pointed out) isn't any particular indicator of success, especially when success means finding the right product rather than doing whatever you were thinking of when you wrote the business plan.

The startup team becomes very important. If the team can work well together and be agile, then it can pivot more quickly. A sluggish team or one that fights itself pivots more slowly.

The question "why do things change so much from startup to stable business?" is also answered: the startup is tasked with finding the product, while the stable business produces the product that the startup discovered. They are really two different businesses, so it's not surprising that people who are involved with the startup tend to drift away once the startup culture begins to evolve towards a stable business.

Are we evolving towards more of a startup culture? Is it possible that some companies might become more like startups all the time? A design firm, for example, is always trying to create new products, just like a startup. As ideas begin to fly through the world faster and faster, the "stable business" part of a product may become less important for many businesses.