Brain Writing rather than Storming

During long driving trips I listen to podcasts, which are better than coffee in keeping me awake (depending on the podcasts, of course). The only downside is that it's very hard to take any kind of detailed notes, so my references are weak. On a recent trip I was listening to (I think) TED talks, or perhaps the Harvard Business Review Ideacast (which has gotten MUCH better in the recent year or so; before it was the usual stodgy old-school Taylorist crap). Anyway, this woman was talking about the work she had done around participative gatherings, something I have a fair amount of experience and investment in.

She observed, as I have, that there's a big problem when you have a group of people together in a supposedly equal setting: the extroverts dominate. Introverts and/or people who don't consider themselves knowledgeable enough (and I have ALWAYS found those people to have very valuable things to offer) hold back. Her solution is what she calls "brain writing" (as opposed to brainstorming, where more assertive people always dominate) in order to truly level the field by bringing ideas from everyone, not just the assertives. It works like this:

• Use very small cards, to reduce the temptation to write essays.
• One idea per card; use 1-2 sentences max per idea.
• Spend 10 minutes capturing ideas (she found people usually slowed down around 5 minutes so this could be shortened).
• “No guessing or confessing.”

The last point means that you shouldn't try to guess who comes up with an idea, and you shouldn't say if you came up with an idea. It's important because the rule guarantees that someone shy knows they won't be outed no matter what, so they have complete security that they can safely suggest an idea.

It seems to me that this technique is more likely to produce more and better ideas -- especially the ideas that are really out there, the ones that could produce breakthroughs.

Hackerspace as Educator & Incubator

On the way to Denver Airport (traveling to the Domain-Driven Design Summit in Portland Maine), I stopped at Denhac, the Denver Hackerspace, to see what it looked like and to drop off some programming books I no longer need. That visit was inspiring enough that, while in Boston, I traveled to the Artisan's Asylum, which is much bigger (40,000 square feet). I found both places to be amazing and exciting. And I've added a new activity to my travel hobbies (the others are speaking at user groups and finding interesting companies to visit): visiting hackerspaces to learn more about them, see how they vary, etc.

Denhac was comparatively small and so everything was shared, whereas Artisan's Asylum rents out private workspaces of various sizes, as well as having all sorts of different machine spaces, welding and metal-cutting facilities, electronics areas, multiple different kinds of 3D printers, on and on -- just about anything you can imagine. One project a team was building was a large six-legged robot, and another group had created a 3D printer pen that I had previously seen on Kickstarter (it raised almost 2.5 million, of a goal of 30K!)

Based on these first visits (I plan to do more), I would characterize Hackerspaces as "machine clubs." Or "shared creative spaces." Or "studios and laboratories." "Teaching about technologies." On top of that they can be small-company incubators. Now that I think about it, it's rather hard to sum up what a hackerspace is. Denhac's website says: "Hackerspaces are simply places for people to learn, work on tech projects, socialize and collaborate."

There's a page on the theory of hackerspaces on Hackerspaces.org. That site has links that tell you how to start a hackerspace, and even has a page that guides you through the various phases and problems your hackerspace will encounter along the way.

Let's consider the "incubator" category in more depth. Because anyone, for almost no expense, and come in and have access to some great machines along with amazing shared expertise, it becomes very low-risk to try experiments. This is the key to innovation: being able to do lots of low-risk experiments. A hackerspace, however, has zero expectation of outcome. The fellow at Denhac told me they were putting together a big cluster of machines build on open technologies "because we can." THAT'S the kind of environment that can create breakthroughs.

Although the idea of an incubator as we've come to know it is a good thing, it's really only a step. The problem still remaining is that it is results-oriented. That might sound like a pragmatic, practical approach but true creativity and innovation often come from precisely NOT deciding that you want any particular outcome (or, if you do need an outcome, precisely how to get there), but simply by following your impulses and doing things just because they seem like cool/fun things to do. It turns out that fun/meaningful produces a lot more motivational endurance than doing something because it has a financial exit strategy (see my post on Dan Pink's book Drive).

I think the hackerspace is also at least a partial example to the question of "where is education going" now that it's beginning to be disrupted (on the one end by the internet, and on the other end by the ridiculous trends of deciding that we the people shouldn't invest in education and that everyon should pay their own way, making the cost of college outragous and excluding anyone who can't foot the bill). If you can get lectures on the internet cheaply or for free, and the lectures themselves are getting better (because the creators know they have no arbitrary hold on the audience -- they have to be fascinating and useful or people will stop watching), then why does someone have to pay a fortune to go to a physical place? Answer: to interact with other people and to use tools they would otherwise not have access to. Both these are provided by a hackerspace, but at a tiny fraction of a cost of a university. Add to that the fact that everyone can learn at their own rate, which solves a big problem of traditional teaching (you have to take all these classes and learn at the proscribed rate and if you don't then you must not be smart. Those of use who learn differently are filtered out and potential greatness is constantly lost from this arbitrary practice).

I encourage everyone to discover your local hackerspace and go visit. Even if you don't join you'll be inspired by the experience. Also please note that I didn't get any kind of special treatment; no one recognized my name. I just showed up and said I wanted to visit their space and they were really happy to show me around.

Every Organization is Unique

You'll notice I've changed the subhead of this blog from "Seeking the Next Organizational Structure" to "Discovering Your Best Organizational Structure." This is a fundamental shift that comes from the first big mental change caused by the Holacracy Seminar.

After spending many years helping organize traditional programming conferences, I decided that this new Internet ought to enable better and lower-cost organization of conferences. Traditional conferences required big investments in mailings and phone marketing to generate registrations. Choosing and scheduling speakers (where I was primarily involved) was an arduous and time-consuming task; much like editing a book of contributed chapters (I did this once).

I was there when commercial microcomputers first appeared. My first computers were a Kaypro 4 and then a Kaypro 10 (with an amazing 10 Megabyte hard drive! It was The Future!). Initial attempts at "computerized learning" simply took learning tools from the real world, like flash cards, and made computer versions of them. It seems naive now to think that this would be anything like the computerized learning systems we have started to see, but at the time it was the best and most obvious thing anyone could come up with.

So it's not entirely silly that the best I could think of for a new kind of conference was to take what we were doing by hand and try to computerize it, with a little crowdsourcing thrown in to, for example, help figure out what presentations would be most desirable. It took a fair bit of delving, struggle, and help from other people before I discovered just how different a conference structure could be (Open Spaces).

It's equally unsurprising -- to me, anyway, having watched myself make similar mistakes over and over before (one hopes) eventually figuring something out -- that I would start with what we've been taught from birth: there's a structure, a single structure, for all organizations (the power hierarchy). Using the same logic I initially applied to seminars, all we have to do is find a different structure -- "The Next Organizational Structure" -- and apply that single structure to all new companies. Problem solved!

This is the first myth that the Holacracy seminar busted for me. If every organization is unique, why would they all end up with the same structure? (Because we've been told so many times that it doesn't even occur to us to question it).

Even if you accept this premise, the thought of developing a unique structure for each company is at first daunting -- again, because we've never acquired the tools to think about the problem. The solution is, again, very different: we don't use the traditional big-bang-waterfall approach where you just impose the structure ready-made, huge and ponderous so it can solve all anticipated problems. Instead, the organizational structure is grown organically, a bit at a time, always on demand (rather than anticipating needs, which produces our current overbuilt and ossified structures).

How does this organic growth happen? That requires the introduction of several other foundational concepts which is delegated to future blogs. For now, just ponder the idea that each organization can evolve its own structure, suited exactly to its own needs -- and change that structure to adapt to new issues as they arise.

Venture Capitalists are not Evil, but ...

When I first started learning about venture capitalists (VCs), I heard about them from the tech startup side, which called them "vulture capitalists" and declared they were only in it to screw over the hard-working company founders. Those were the scary stories one heard, anyway, because everyone else was too busy working on their companies.

Many years later, and after having a girlfriend who was in social venture investing (different goals but much in common) I'm of the belief that the majority of VCs are not evil, but there are enough of the evil ones out there that you have to be very careful to choose one that shares common beliefs with you about business. The right VC doesn't just provide money, but nurtures the company in numerous ways, providing guidance and expertise. Sometimes they need to make some hard decisions that you can't make, but the right VC will make those decisions in the interest of the company and not for short-term greed.

Pitching to VCs should not be a one-sided trip to Vegas, hoping to hit a jackpot. It must be a two-way interview to discover if you can work together. You might be anxious to get funding, but funding from the wrong place can destroy years of your life. Here's an article that shows what can happen, and why you should pay for your own lawyer in the process. (The idea of hiring a lawyer is expensive and scary at first, but there are times when cutting corners in the short term will cause much grief in the long term).

It's also important to realize that venture capital is not right for everyone. If you can bootstrap yourself out of your garage while working a side job, there are more and more opportunities for that (for example, launching anything big on the web used to require setting up server farms, now anyone can scale through the cloud). And if you're building a product, what better way to fund the first production run and find out whether people actually want it than services like Kickstarter? Other forms of investing are beginning to appear, as well.

To begin learning more about this, I recommend the Stanford Entrepreneurial Thought Leader podcast; it's worth going back and listening to all of them (I find them very stimulating during drive time).

Hierarchical Communication

Clay Shirky gives a very good description of how information gets distorted moving up and down a power hierarchy. Here's a little story, told in bible-speak, which shows the distortion in action.

Work Is Not A Job

I like this site. Kindred spirits.

Anti Consensus

Although he has spent many years hilariously lampooning management foibles, when he tries to come up with solutions the cartoonist Scott Adams seems to produce cartoonishly oversimplified conclusions. Although I think there's some truth in his assertion that "Management exists to minimize the problems created by its own hiring mistakes," it seems naive to say that's the only reason for the existence of management. And it's great that he has a decision-making system that works for his small team, but it's basically consensus, which has fundamental problems:

1. Consensus is the slowest possible decision process, excepting probably war.
2. Consensus is a very heavyweight process. This means we resist revisiting a decision because it's so much trouble. Decisions made become ossified into your system.
3. Consensus doesn't scale. In Adams' own case, right now he has a group that can quickly make decisions because they're already in agreement (or could it be that they're already in agreement with Adams, in which case you have the charismatic leader problem and you're not actually evaluating decisions on their own merit). Bring in a new person to the process -- it becomes a many-body problem in which any one person can bring everything to a grinding halt.
4. Consensus filters out differing viewpoints. Differing viewpoints are exactly what you want in order to make the best decisions and build the best systems. If Adams wants rapid consensus, then a "hiring mistake" is "anyone who doesn't already agree with us," and you end up with the rookie move of hiring yes-persons.
5. Compromises produced by consensus are always worse than mediocre -- there's a yawning gap between "a decision everyone likes" and "a decision everyone can put up with." The easy issues are great, when everyone is already on the same page. But when you solve a challenging problem, you must go into uncharted territories where there will be disagreements

Aside: This has me wondering about agreement in general -- how important is it in a relationship? Consider the extremes:

• We agree on nothing. This sounds like "irreconcilable differences." Can you have any kind of relationship when you can't agree on anything? This is a new question to me so I haven't figured out how to approach it.
• We agree on everything. First, I wonder if anyone would believe it's even possible to agree on everything. But if the other party could back up their agreements with, say, rational arguments, or by citing a shared religious document and/or news media outlet (conforming to a particular interpretation process) then it could be convincing. Initially it would be very satisfying to find someone "of the same mind," but at some point having a perfect echo chamber prohibits growth, and I believe we have an innate growth impulse which, when stifled, eventually causes fractures in our world.

I guess, in order to move forward, we need some level of agreement about "the basics," and perhaps most of human cultural evolution and the ensuing clashes are around what those basics are.

Anyway, Holacracy uses the diametric opposite of consensus: instead of getting everyone to agree, Holacracy looks for a legitimate objection, with precise tests to determine legitimacy. If such an objection surfaces, then the proposal is modified to resolve that objection. You end up with a proposal that some people might not be happy about, but if there are no legitimate objections you incorporate it -- with the essential caveat that it can be revisited at any time. The lightweight nature of the decision process and the ability to revisit a decision allows for experimentation, which is an essential factor in Holacracy. A management system that says it promotes experimentation but requires a heavyweight process to actually do experiments will end up stifling innovation.

People talk about a company being a "victim of its own success." This actually means that the organization and decision processes worked great in the small, but didn't scale. So far, my analysis of Holacracy -- which is not a design for a company structure, but rather a process for designing the unique structure of your own company -- is that it does scale, at least significantly beyond what we see as the critical junctures in the growth of companies using the old model.

Visit to Riot

I spent Friday at Riot Games (here I am, speaking about error handling). This was one of the most stimulating and mental-input-producing company visits I've had and there will be lots to think about and digest over time. However, I signed an NDA and game companies are very careful about revealing information, so to be safe I can't really talk about any of it. Suffice it to say the experience was very worthwhile.

Riot makes League of Legends, a phenomenon in the world of multiplayer online games, specifically a Multiplayer Online Battle Arena (MOBA) game. There are millions of players throughout the world at all times (in Korea, if there's an outage it gets reported on the evening news).

League of Legends is strictly a team game -- you always play in a team, even if it's a team of robots. At the recent Game Developers Conference, Riot revealed some results of the research they've been doing on shaping player behavior -- the game is intense and players can behave badly toward each other (bad behavior on the Internet? Shocking!).

A game like League of Legends could be exactly the kind of revealing interview game I was talking about here. Clearly, it produces the kind of "decisions made under pressure" that reveal someone's true character. Not only that, it produces some teams that work extremely well together. I can imagine forming optimal teams through an online game (perhaps one more tuned towards business) and then moving those teams into the real world.

The Hubspot Culture Code

Another alternative management approach. Slide deck (worth going through to the end) here.

Self Management

My friend Dave sent me a link to this article that gives a brief introduction to what they call "Self Management." It has some similarities to Holacracy but what's described here gives me the feeling that it's not necessarily as finely-honed.

Since they are fundamentally a tomato-processing company, it seems like they might have produced one example of a result that could be more systematically produced via Holacracy. However, there's not enough in this article to know for sure.

Next time I'm in the Bay Area I'll try to visit them and see how they compare to Holacracy.

Edit: It turns out there's an article on the HolacracyOne Website addressing this very issue.

The Interview Game

I haven't posted about the Holocracy seminar yet. There's still a lot roiling about, requiring mental digestion. And more than digestion: rebuilding my world view (many changes were already taking place from the work reported in this blog -- I was ready, but just barely).

Brian Robertson (the creator of Holocracy and our seminar leader) came from the software field so it's not surprising that he refers to Holocracy as a way to build the "operating system" for your company. He says that the operating system only covers the core parts of the company structure, and that everything else is an "app" which your company creates according to its needs. Some of these "apps" include hiring, firing, and determining salaries. Brian admits that these are fundamental to most organizations and that some kind of prototypical apps might eventually be produced by HolocracyOne (the company behind Holocracy, which of course is organized via Holocracy).

I've struggled a lot with the hiring process. There are so many things about it that are wrong, but we don't know any better so we keep doing them. The impact of bad hiring is nothing short of huge: the amount of time and effort bringing in a bad hire, the resultant time we allow that bad hire to do damage (because of the sunk cost fallacy), the impact of recovering from that damage, the time and costs in getting a bad hire out, and, not least, the cost to the person who is hired when it doesn't work out (they've often moved across the country, for example). Hiring and firing are some of the heaviest-weight processes we have in an organization. We need to make them lighter-weight (which I will not address in this posting) and at the root, we need to make the hiring/on-boarding process much more effective.

"This person seems to paddle a canoe pretty well. So they'll probably be a good swimmer!" Sounds ridiculous, but it's exactly what we do when we test how well someone interviews and assumes that will have any bearing on how well they work. We keep using interviews because we can't think of any better way to solve the problem.

An interview is a test that doesn't produce very useful results. We need better tests. We want to know how a person will work within a particular job, so our tests need to get a lot closer to the job they're being interviewed for. If you're a programming company interviewing a programmer, you get slightly closer to the mark by asking programming questions, but the context is usually wrong. Nobody writes sort routines as part of their job, and nobody solves programming problems at a whiteboard. And if you get someone who is good at solving problems at a whiteboard you might have a bad fit (you actually want someone who uses resources like StackOverflow to get to the answer quickly rather than brain-wrestling it to the ground from first principles).

You usually want someone who solves problems expediently in the context of a team. Whiteboard exercises do not test for these abilities.

When I talk about this problem, I often use the analogy from storytelling: the persona is "who the character says they are," while the true character is only revealed through decisions made under pressure (the storyteller's job is to put the character under pressure and force them to make decisions in order to reveal this true character). So to find out how a person is going to behave under real circumstances, it seems you must somehow simulate those circumstances -- and the decisions under pressure that go along with them.

This leads to all kinds of challenges -- one can imagine faking situations in order to produce reactions. Which ultimately violates transparency. Perhaps there's a better way. In particular, we tend to think of "pressure" in the negative sense, and this is the essence of my insight:

Can there be positive pressures as well, and can we use those to solve the problem?

Here's where I go far off the beaten path with some wild speculation derived from middle-of-the-night inspirations. So feel free to discount the rest of this posting; I won't be insulted.

Suppose we create a set of two-path questions, where you must choose one path or the other. The questions are hypotheticals which are not specific to jobs or working -- more like a game (and the feeling of being a game can relax the participants and make the results more natural). Ideally the questions might be able to build on one another like playing "Dungeons and Dragons." The questions are randomized into a sequence for a particular hiring process, then all the current members of the team take the test and their answers are captured and turned into a pattern that represents the team. The candidates also take the test and the pattern that most closely matches the team's pattern is judged the best fit.

Agreed, this system is pure guesswork on my part (it seemed so brilliant when it woke me up in the night) -- there's no way to know whether there would be ANY correlation between the results of this test and the fitness of a candidate. But it has a few things going for it:

1. It's about as rational as assuming our current approach has any correlation. Perhaps it's even more rational because with my test we actually don't know what the result would be whereas with traditional interviews we know the results are very bad.
2. It's virtually impossible to anticipate and prepare for my test -- you can't game it.
3. If nothing else, the test could be a fun game to break up the monotony of the interview process and relax people.
4. It might a step on the path to a better system.

If the idea still seems to crazy to consider, it's probably just this.

Timeboxed Thumb-Voting for Discussions

One thing I learned at the Holocracy seminar came from a side conversation with one of the attendees; he initially introduced it as "agile coffee" although a search for that did not seem to reveal this particular technique.

Some background: when I was becoming bored with the way the Software Development Conference (now defunct) and similar conferences were working, especially considering the rise of the Internet, I began talking to people about trying to create a new kind of conference. Many thought it was an interesting idea, but Martin Fowler said "let's do experiments." We created the Enterprise Architecture Summit, an invitation-only event that ran for a number of years in Crested Butte, Colorado where I live.

Initially we put up big sheets of paper and people wrote topics of interest on them. Then we used "dot voting" where everyone has a fixed number of dots and can distribute them as desired (including putting all your dots on a single topic if you desire). Then the topics were discussed starting with the one that has the most dots.

This was a smaller group and we were all in a single room. A majority of the attendees were experienced authors and speakers and had no trouble producing lots of words, and therein lay the problem: with such a captive audience it became far to easy to fall into lecturing mode, which tended to stymie discussion and produce frustration.

At one point I even created signs for everyone, with red, yellow and green sides to indicate "stop now," "start bringing it to a close" and "keep going." People didn't really use the signs but their existence seemed to significantly diminish the tendency to lecture.

I think the problem with the signs was that anytime someone decided to change theirs, it was kind of a big deal, a rather noticeable event that made you stand out. Whereas if changing sign state is just something we're all doing as part of a pre-agreed process, you only stand out if you don't participate.

This is where time-boxing comes in. The discussion runs until the timer goes off, then everyone chooses: thumbs up for "continue the conversation," thumbs down for "end the conversation and move to the next topic," and thumbs to the side for "a few more minutes to wrap it up." The facilitator then makes a judgement call on minutes for the next timebox. (I could be wrong about some of these details; the description happened quickly).

Martin had discovered Open Spaces before we could solve the single-group discussion problem. The next time the opportunity arises I want to try this technique.