Reinventing Business
Discovering Your Best Organizational Structure

Tuesday, November 18, 2014

Heterarchy and Adhocracy

Heterarchy and adhocracy are two terms I came across when searching for hackerspaces while in Scotland.

Loss Aversion

When I was a kid, I remember being willing to jump into something without worrying about how it might come out.

Until you know things will turn out OK, there's always the potential that you could run into a problem that makes the whole effort a waste of time. In cognitive science, the bias against any kind of loss is referred to as "loss aversion."

"Loss" is a future-oriented idea. When we are kids we're much more in the present, thus willing to try something without requiring success. We're natural experimenters. But as we grow older we are taught not to "waste time" by doing activities that don't have guaranteed results.

I wonder how much of my life has been bound up by performing cost-benefit analyses on every possible option. This process, spun up decades ago, requires some certainty of outcome before allowing any kind of action.

Anything that amplifies loss aversion increases the gridlock.

No wonder the Buddha emphasized "detachment from outcome."

Tuesday, November 4, 2014

How Diversity Works

In Neal Ford's opening keynote for Geecon in Prague, he includes "diversity" as one of the things we are doing badly and not really paying attention to. Neal was specifically talking about women in programming, and he commented that "there's no down side" to diversity.

I'll argue that there is a "down side" which makes people resist diversity, and is also the very thing that makes diversity essential. It's this: when we're all the same, we all agree with each other easily and most of the time, and that's ... easy. When you introduce diversity: women and people from different cultures (including cultures nested within your own), you introduce the discomfort of disagreement, and that's precisely the point.

A design created by people that think the same way will be the same, and while it might sell to other people like those who created it, it won't address the needs and interests of people outside that group. More importantly, it just won't be as creative.

In the industrial age, design took a back seat to "following orders." Bad designs got pushed through to mass production. Consumers had far less choice; products could be forced into the marketplace. Information about products -- such as reviews -- could be "managed."

In the information age, the tables are turned. Consumers are just beginning to learn what level of choice they have, and new companies are just beginning to learn how to discover and provide what consumers want (this is the actual meaning of the word "marketing," which unfortunately has come to mean just "selling"). Older companies are struggling because, I believe, their structures are not designed for innovation.

It's not as simple as just introducing diversity. Diversity is a necessary but not sufficient condition for innovation in the information age.

There's an interesting elephant in the room when it comes to diversity, one which I think diversity advocates have avoided because they're just happy to be part of the discussion. If diversity introduces (important) disagreement, how much diversity can you stand? How much disagreement is beneficial, before you cross a line and it becomes divisive? An organization with a lot of chemists and physicists, for example, will probably benefit greatly by introducing some biologists and sociologists, but will it help to bring in non-scientists, specifically people who believe without evidence? The answer probably depends heavily on context (what products are you making?).

Another important aspect is communication tools. When we were non-diverse, we agreed more easily and communication could be local-cultural. With diversity, we need to focus more on ways to communicate across bigger cultural divides.

Friday, October 31, 2014

Geecon Prague (Rest of Trip)

Wednesday began with a brief meeting at Infor, an enterprise consulting firm. I've had a little improv training, and many of these meetings are like that -- I know almost nothing going in and so just have to make it up as I go, and most importantly, be happy to go where it takes me. I find that what I usually learn from a meeting is rarely what I think it might be, and it often comes to me days or weeks later, in a flash of insight.

A group of us then went to Node5, a combination coworking space and business incubator. I really liked the space and the way they combine the two functions, something I've seen before and feel like is a general trend (first create a space where people can come together without having to be a business, then do things that might help team formation and business creation). Ultimately I hope that the process of forming businesses continues to evolve in a direction that makes it easier and more gentle, which I think will open it up to a lot more possibilities. There are a bunch of people -- the majority, I would wager -- that don't find the aggressive business culture to be attractive. As a result, only the aggressives end up starting businesses, so it's not that surprising that the resulting culture is aggressive. But there are a whole bunch of possibly-revolutionary products that don't fit that mold, and thus don't get made. And then everyone misses out.

My impression is that Node5 doesn't require individuals to create or join teams, but the environment encourages it. This allows people to gestate for however long they need before joining or starting a company, and for teams to get to know people before asking them to join. And they seem to have a natural progression as a company grows -- if it is successful and making more money, it can move into one of the closed-off peripheral offices at Node5. I'm not sure whether their approach is optimal, but I really like the general idea of setting up a minimalist structure that encourages movement in a particular direction but doesn't require it to happen on a particular schedule.

We had a lunch at Node5 with people there who had signed up to attend; the turnout was less than the signups, and Node5 in general was (I was told) much less busy than normal, and this was attributed to rainy weather. Apparently folks in Czech are much more likely to change their plans because of weather, whereas in Scotland (where I'm writing this from) no one would think of doing that or the country would grind to a halt. I don't worry about turnout; smaller groups are more intimate so it's always interesting regardless of whether the group is large or small (one Open Spaces "rule" is "whoever shows up is the right people").

In the evening I held an Open Spaces session. As usual I spent about 20 minutes explaining Open Spaces and then we created discussions. The goal was to have three sessions, but after two sessions pizza arrived and we never got around to the third because people got into all kinds of conversations over the food. Since the point of Open Spaces is to create conversations, I don't worry when things like this occur, and have learned over time to let things happen the way they want to (another Open Spaces "rule" is "whatever happens is the only thing that could have").

During the conference, I not only heard speakers refer to conversations they'd had during open spaces but attendees came up to me and said how much value they had gotten. At least one person said they were going to try organizing their own. I quite enjoy being an advocate for Open Spaces, and the best way is to just hold them and give people direct experience in how well they work.

I did not speak on the first day of the conference (Thursday) but Neal Ford gave easily the best presentation I've seen him do, as the opening keynote. It probably resonated so well with me because he was pointing out places where we've gotten stuck doing less-than-optimal activities. One of the first things he said was especially helpful: he pointed out that branching and merging for feature development was counterproductive, for the same reason that parallel threads of execution need locks on shared resources. This produced a kind of sigh-of-relief effect for me because I've always wondered about this but assumed that I just didn't fully understand the paradigm. It's very helpful when a thought leader like Neal points out the problem because it helps people get onto the same page.

I went to a number of other talks on both Thursday and Friday. For me the most important was the Kotlin presentation, because I'm seriously considering "translating" Atomic Scala to Kotlin. JetBrains (supporter of the Open Source Kotlin project) had a booth and I spent a bit of time talking to them about the possibility. At the Scala Summit a number of us spent a bit of time studying Kotlin, and my objective was to be on the lookout for reasons not to do this translation. So far things continue to look good.

Friday I figured out how to take the underground from my hotel in downtown Prague to the conference venue which was held in a multi-screen movie theater (inspired by Devoxx). These sorts of mini-adventures in using a foreign transportation system are good for the brain -- puts me in "beginner's mind."

I gave the closing keynote for the conference. A closing keynote can be tricky, because it needs to bring things together and tone them down, while still remaining intellectually stimulating. Mine was called "Do Languages Matter?" which evolved from last Spring's presentation to the San Francisco Scala User Group, but is significantly different. The new slides are here, and the video will eventually be available through Geecon (I'll post the link when I get it).

One point that I kind of casually threw into the presentation at the last minute ended up prodding at my mind. I originally wondered whether to include it but I eventually realized it was key to a new way of thinking. This is the "gift" that I've come to watch for when traveling, as described in Joseph Campbell's monomyth, wherein the main character journeys outside of his or her comfort zone, experiences a series of challenges and eventually changes and (often) returns with some new knowledge or understanding that enriches the world they left. But that insight is the subject for another post.

Wednesday, October 29, 2014

Geecon Prague Day 2 and the Latest "Reinventing Business" Presentation

In the morning I was able to visit Y Soft's factory area. Many years ago when I worked at Fluke, our project (the Fluke 45 Multimeter) was the first in the company to use surface-mount technology, but I never got to see the manufacturing system in action as I finally did at Y Soft.

Adrian and I drove back to Prague, where I met with the Y Soft CEO for a general discussion.

That evening I gave the latest version of my "Reinventing Business" presentation. I've started to realize that these change so significantly from one presentation to the next that I need to start giving them subtitles to differentiate them -- almost as if they are chapters in a book. This way, people can distinguish the different presentations they find on the Internet.

I called this one Reinventing Business: Audacity and Humility, because I was primarily looking at the assumptions of determinism in popular business books (and the ridiculous nature of their claims). I then asserted that business was probabilistic rather than deterministic (thus the need for humility), but that you can still work the odds in your favor by doing lots of experiments -- most of which will fail (and thus the need for audacity, to keep trying).

In the days that followed I had a surprising number of people tell me that the presentation had sparked thoughts and conversations -- this is very gratifying to hear.

The presentation was filmed and will eventually be available on the Internet.

Monday, October 27, 2014

Geecon Prague Day 1

Last week I traveled to the Czech Republic to speak at the Geecon conference, which was held for the first time in Prague (in addition to its normal venue in Poland). I Followed my current practice of adding extra days to a trip, and asking the conference organizer to help arrange visits to various organizations beforehand, including companies, incubators, coworking spaces, hackerspaces and anything else that might produce new and interesting ideas.

Landing in Prague Sunday night, I was immediately whisked off to Brno, about 2.5 hours by car. Monday morning I went to Y Soft, where everyone was standing outside and there were fire trucks arriving. The fire was minuscule but it had affected the air quality so we walked to a building that held a startup incubator to hold our meeting.

This was primarily an introduction to Y Soft and some of its principals, but what really woke me up was hearing about Y Soft's business incubator program. Y Soft is itself a bootstrapped startup -- they didn't take investment money to get where they are -- and now they are incubating four other startups. That is, Y Soft itself is the incubator. I've certainly heard of companies acting as venture capitalists (HP, for example, has a VC investment division with quite a bit of money), but this is quite different. First, Y Soft isn't that big; most companies wait for quite awhile before doing things like this. But more importantly I see the fit as being especially good. The four companies they are incubating are all tech companies, often with both software and hardware components. As a bootstrapped startup itself, the people at Y Soft are well-qualified to give very salient advice. The startups are co-located in Y Soft facilities, so the incremental costs are (I suspect) relatively negligible. But I think the most exciting part about this venture is that Y Soft engineers can get involved with helping the startups (something Y Soft is working towards). This seems like an important resource, unavailable to the typical incubator. I think it will also be inspiring for the engineers to help with startups, producing a higher sense of purpose as well as a greater belief in Y Soft's mission. In addition, if for some reason a particular startup doesn't work out, it seems very likely that Y Soft could employ the displaced members.

I see this approach as not only a new model for incubation, but also a new model for innovation within existing corporations. Rather than the typical top-down approach of analyzing "what will be successful" by senior management and deciding what to fund, why not find teams that are pursuing new ideas and incubate those? Financially it makes more sense as well: big companies wait until a startup becomes successful and then buys it for big money. Why not start investing earlier (as well as helping the company become successful with coaching and other resources)? It seems like it could be a lot cheaper to be involved at the more experimental stage. Perhaps we are seeing the dawn of the future of research and development.

I was then taken to Kentico (which makes a .NET content management system), where I first had a discussion with the scrum masters; their topic of choice was "What is Agile Architecture?" This oddly coincided with the publication the same week by Martin Fowler's essay titled Sacrificial Architecture, and with someone describing to me the "Phoenix Pattern" wherein you burn down your existing architecture and replace it anew, based on everything you learned the last time around. There seems to be a fundamental shift afoot in way we think about architecture. This might be arising from experience in REST APIs and microservices, where the separation between the architecture that produces services and the consumer of those services is so distinct that it becomes possible to rebuild the architecture and replace the old with the new.

Later the CEO and CTO of Kentico joined us and the conversation continued. One thing I find particularly stimulating about these kinds of meetings is their improvisational nature. I typically have little or no idea what is going to happen in the meetings and so I must be fully engaged and in-the-moment, allowing whatever is going to happen and flowing wherever the discussion wants to go (much like Open Spaces). In addition, what I learn from these meetings can never be anticipated and is always a surprise.

One meta-surprise is that I've been finding organizations appreciative when I come to visit. My own perspective is that they're doing me a favor by spending time with me, but apparently they often find that I somehow bring value, perhaps just by catalyzing conversations and bringing perspective and insights from my research and from other organizational visits (I'd like to think so, anyway). I wonder if I'm not incidentally practicing for some different form of management consulting which, in the same vein as Open Spaces, acts by starting conversations.

Aside: the primary reason I've been reluctant to describe any kind of personal goal for the Reinventing Business project is that I am more and more cognizant of the pitfalls of the world of management consulting. All you have to do is promise the world and someone will pay you a lot of money. Once you go down that path the temptations to continue are tremendous. But I want to make a true and big impact on the world, to fundamentally change the way we create business and do work. Fortunately I've had lots of experience walking away from things that I could have continued to develop into bigger income sources, I think because I've always felt there's something more satisfying and meaningful out there (in hindsight, I'm not great at figuring these things out particularly quickly, but I do it).

The final meeting of the day was with a group in the Masaryk University computer science department, where folks from Y Soft (who also participate in university education), myself, and faculty members discussed the creation of a new course in software quality. Although I remember it as a lively and interesting conversation, I think that the first-day jet lag was getting to me so the details are a bit fuzzy.

I would like to acknowledge Adrian Nowak who put in the time and effort to arrange these meetings and to get me to them. On one of my previous trips to Poland we began joking that Adrian is my agent, and this year two other members of the Geecon staff decided that they should be Adrian's agents as well.

Monday, October 6, 2014

Deterministic vs. Probabilistic

Along with The Management MythThe Halo Effect should be required reading for anyone considering a business management program, whether undergraduate or graduate. The first thing you should know about such a program is how bad the science really is, and this book gives you a face full, in particular debunking the most popularly successful bestsellers like In Search of Excellence and Good to Great. The worst thing about books of that ilk is that they pretend to do even more research than the previous bestseller, but all the research is either based on previous bad research, or sometimes creates new bad research, and the conclusions drawn by such books are equally bad.

The Halo Effect refers to the idea that, if the company is financially successful, people tend to ascribe all kinds of other good things to the company. If the company is financially unsuccessful, those identical activities are given negative connotations. Basically, you can't rely on people within a company to give unbiased feedback about the company. Unfortunately, popular business books do exactly that when gathering their so-called data: they survey people within the company, asking subjective questions about how good or bad the company is doing such vague things as "establishing a good corporate culture." It turns out to be a lot easier to do such "research."

The author, Phil Rosenzweig, points out that the reason some business books are so successful is that they tell a good story -- a story that people in management want to believe, which is usually some form of the "rags to riches" fable wherein the hero is able to control his or her own destiny. "You too," these books say, "can make your company successful if you just follow our formula!"

The Wikipedia Article and this analysis and this one review the book fairly well and I don't need to try to better them. There is, however, a portion of the book where I feel Rosenzweig lost his focus a bit. The last of his Nine Delusions is "The Delusion of Organizational Physics," wherein business-book authors claim that everything is deterministic and if you pull the right levers (following the formulas described in their books) you will absolutely get your desired results, every time, as reliable as dropping an object in a gravitational field.

This is straight from Frederick Winslow Taylor, who decided he was "the father of scientific management," for some alternate universe where "science" means "making up data to support whatever you want to at the moment." Taylor was "successful" because people paid him money for his stories, so others followed his lead. And managers really liked the story that they had complete control over their own destiny, which was Taylor's gift: the belief in deterministic management.

Rosenzweig debunks this but only replaces it with "strategy and execution," which is on the same level as saying "a company must make a profit to stay in business." Yes, you have to plan things, and you also have to do things. But can't we know something a bit more than that, something that will at least slightly tip things in our favor?

Rosenzweig points out that there are far too many variables to be able to either measure or control the actual effect of changes. And he also notes that running a business is significantly affected by chance, but he doesn't quite shift over to the thinking found in The Black Swan: that being in a world containing risk and unpredictability doesn't mean you're helpless. Taleb says on page 368 of The Black Swan:
"... people do not realize that success consists mainly in avoiding losses, not in trying to derive profits. ... Positive advice is usually the province of the charlatan. ... Linked to this need for positive advice is the preference we have to do something rather than nothing, even in cases when doing something is harmful. ... in many instances it was better -- and wiser -- to have no models than to have the mathematical acrobatics we had."
Such a world is certainly not as comfortable as the imaginary one where everything is deterministic, but it doesn't mean we can't do anything about it. The change in perspective is significant, and might be too big for most (many people seem determined to remain in fantasyland) and doesn't promise absolute power over everything -- but at least the results are real.

In his RSA presentation for his follow-up to The Black SwanAntifragile, Taleb lays out this strategy, which I've paraphrased here:

  1. There's no guarantee of success, so treat everything as an experiment.
  2. Assume most experiments will fail.
  3. Assess the risks on each experiment, and make sure that if that experiment fails, it won't take the whole enterprise down with it.
  4. Realize that even if an experiment is successful, environmental (market) conditions might not favor it.
  5. Sometimes you will experience "luck," when an experiment succeeds and positive market conditions produce a popular product.
  6. Thus: Look for experiments that have a very positive upside with a non-disastrous downside.
  7. Do as many of these experiments as you can manage.
There you go. "Seven habits" that actually work (for some definition of "work"). Note that this shares ideas with Eric Ries Lean Startup approach.

Monday, August 4, 2014

Turn the Ship Around

What makes this book unique is that the author, former nuclear sub commander David Marquet, describes how to change the workings of a hierarchy, without changing the hierarchy. He had no choice, because it's the Navy and they weren't about to change the command structure to perform an experiment. So instead he changed the relationships within the structure.

The essence of his approach is to change our existing hierarchical relationships, which he calls leader-follower, where the leader gives the command and the follower executes it, like a machine. This is dehumanizing and disempowering for the follower. Taken to the extreme, you get the nuclear sub Santa Fe before Marquet took over, with a disengaged crew that were just going through the motions.

Step-by-step, Marquet converted the Santa Fe to what he calls leader-leader. Although he didn't put it quite this way, my interpretation (colored from my experience in the Holacracy training) is that the subordinates don't wait to be told what to do; instead they announce what they intend to do and only if there is a legitimate objection (that's the Holacracy part) are they prevented. This retains the chain of command while giving the subordinates maximum independence. The results seem phenomenal -- when things need to happen, they just start happening by themselves. The higher ranking officers are simply monitoring what's occurring (to ensure something undesirable doesn't happen) rather than initiating all actions. The result is that the speed of operation is much faster, which is contrary to what we've been trained to think ("if someone doesn't have central control, then everything will grind to a halt").

This didn't happen seamlessly. Marquet explains an earlier experiment that failed, and also describes his mistakes and missteps during the process of converting the Santa Fe. This is particularly valuable because it shows that you shouldn't expect instant results or a smooth conversion process. Everyone has to learn during the transition. But it also shows how to adapt and overcome the problems.

Ultimately I'm seeking an organizational structure (or, as with Holacracy, a way to discover your particular structure) that produces the best experience for the worker-stakeholders. A hierarchical power structure will always be vulnerable to changes in management. However, it's very inspiring to see what can be done within an existing hierarchy, and many lessons can be learned from this book for people who want to make the transition to a flat structure, or even to incorporate people who come with a hierarchical mindset. In addition, you might not be in a situation where you can change the organizational structure, and Marquet's approach is a way to produce big improvements within the old structure.

Finally, kudos to Marquet for all the work he did creating a book that's easy to read. The structure and narrative compel you through the book. Too many authors lose sight of how important readability is, and their message is lost among prose that is unclear or often just too much.

Thursday, July 24, 2014

Joel Spolky's Spinoff

I'm not arguing prescience here, but it's certainly interesting that I wrote about spinoffs right before Joel announced Trello as a spinoff. For people who were wondering what I was talking about, that's an example.

There is one thing I'd watch out for, however. Trello sounds like a great place to work, but the reason it is great is because all the good things in this system flow from management. This means it is vulnerable to changes in management. A benevolent dictatorship only lasts while the dictator is in power.

I think I'm becoming a process-and-mechanism guy. This probably comes from reading too many hand-waving business books that say "things should be this way" without describing how they get that way, and how they steer that particular boat. Even if you do have process and mechanisms, I'm going to ask about stability -- can the change of one person change the company? I'm absolutely not arguing for consensus, but rather a system where the people who are affected by the decisions are somehow in the middle of making those decisions (Holacracy is an example of such a process). Otherwise you're taking a huge risk if you invest your time in that company, by putting all the power in a hierarchy that can be hijacked.

I know Joel, although our last interaction was when I gave a presentation at the Stackoverflow launch in Virginia. The next time I'm in New York I'll make it a point to go visit Trello and find out in person how he intends to maintain that "business operating system."

The Logical Fallacy of Magical Thinking

“Whether you think you can, or you think you can't, you're right.” -- Henry Ford
Not exactly. If you think you can't do something, that is a necessary and sufficient condition to prevent you from doing that thing. "Necessary and sufficient" means "you need it, and if you only have it, it's enough."

The converse of the previous paragraph is "if you think you can do something, then you can do it," a form of magical thinking. Taken to the extreme, we hear "all you have to do is think it, and it will (somehow, magically) happen."

Positive thinking is a "helpful condition" to be able to accomplish something (that is, it's possible to accomplish things while practicing negative thinking, but that's an uphill battle and way less fun). There are activities for which it is even sufficient. For example, positive thinking will improve your state of mind, and will probably even make you physically healthier. Things that are hardwired to the brain will probably be affected by the activities of the brain. Positive thinking might even have a positive influence on other people's brains (I've heard of some mass-meditation experiments that seemed to have positive effects, but we have to treat those as hearsay for now).

We have no repeatable evidence showing that positive thinking will allow you to walk unaided on water or "attract" money or love (although a positive person is certainly far more attractive for doing business with or falling in love). Or start a business and create a product based on antigravity. Such a business will probably need a lot of positive thinking, but that won't be sufficient. We'll also need to know enough about the laws of physics to figure out some way to actually produce antigravity. And once you figure that out, a grumpy company could still make a go of it (but again, less fun).

By all means, think positive. It has overwhelming benefits. The only downside is when you believe that thinking positive is all you need, which puts you on the slippery slope to magical thinking. Think positive, but maintain a healthy skepticism.

Tuesday, July 22, 2014

Spinoff Machine

Reading this article and comments about Microsoft's new CEO and his sketchy-sounding recent positioning memo made me observe:

  • The industrial-age corporation desires power, and sees acquisitions as a path to power.
  • Most acquisitions (80%?) are considered failures.
  • Acquisitions add to the number of products controlled by a company. 
Or, do the products control the company? When you have a product, you have a thing you must manage and maintain, and most importantly, you have a thing that incentivizes you not to rock the boat. Add to that the goal of the organizational hierarchy: to do the same thing over and over. These, and I'm sure other forces that I haven't considered here, make it nearly impossible to innovate.

What if a company reversed its goal? Instead of trying to get bigger, it intentionally stays small. After it creates a product, it spins off a company for that product. The spinner gets money back from the spinoff, perhaps diminishing over time, and the spinner can go back to creating new products, unencumbered by the spinoff and its product. The spinner stays small, agile and innovative.