As I mentioned earlier, I’ve been in a management off-site this week. A lot of the work there has simply been about communicating where we are right now, with a fair amount of time also devoted to communicating plans for what we will do over the next eighteen to twenty-four months.
This is all necessary activity and if we weren’t at least trying to be serious about planning for the future we would be negligent as managers. The problem of course is that any manager with any experience at all knows planning is mostly futile. As many hacks have pointed out, it is a rare plan that survives the first shot on the battlefield. (And yes, we always revert to tired combat analogies in having these kinds of discussions, which is counterproductive at best. Business is not war, and selling free software is most certainly not war — more of a parlor trick, I sometimes think.)
I don’t need tired combat analogies to demonstrate the futility of planning — I can use my own career in software. Since I got into this dodge back in 1999, I’ve been involved in at least ten different software projects where the work we were doing was based on realizing some imagined future state that was more than a year out. Not a single one of those projects ever realized that planned state. That doesn’t mean they were failures, although many were — this is software after all. It simply means they didn’t go to plan.
So what is the point of even discussing “roadmap” (as we call it) in an industry where even our CEO says things like “Planning is dead?” I guess one alternative is just to be totally reactive — build a team that is super flexible so it can quickly jump on whatever opportunity arises. Nice idea, but hard to pull off in nature, partly because teams like this are expensive. Also, “totally reactive” doesn’t feel like a great way to be when people’s careers are depending on your leadership. We are compelled to try to imagine the future and try to position ourselves and the people who depend on us to take best advantage of it.
No, I think it’s best to continue planning, knowing all the while that the plans will be wrong. It’s just important not to depend on the outcome.
I was talking to a European colleague the other day about the differences between Europeans and Americans. He blew my mind with an idea I had never thought of before: It all comes down to show and tell.
I don’t really know why we even have “show-and-tell” in preschool in the US. I should probably ask one of the teachers in the family to explain it to me at some point. At any rate, my colleague holds that show-and-tell is a reason, if not the reason, why Americans tend to be so much louder than Europeans, and why we’re so much more comfortable standing up and talking to a group. Not just comfortable, really — more like compelled.
So what’s so special about show-and-tell? At age three or so, you are required to stand up and talk about a thing you brought with you from home that you think is important. If you do it well, you are praised for it — and you watch other kids being praised for it (or heckled if they do it badly). If you like being in the spotlight, you’re going to find out at an early age, and you’re going to want to keep going back there.
Apparently this kind of thing doesn’t exist in European primary schools, according to my colleague at least. I don’t have any inside knowledge of schooling in western Europe, but all my Czech friends have told me that “standing out” in school is a great way to get singled out for abuse or worse. They say this is yet another anti-pattern from forty years of communism. Anyway, standing up and being noticed is definitely not something Czechs are into, with the required exceptions of course.
Americans’ desire to stand up and talk is not entirely a virtue, of course — to other cultures, we look boorish, self centered, and rude. We’re also impossible to miss. Kim and I used to sit in cafes in Paris and guess the Americans walking down the street — you can just about do it with your eyes closed. Just listen for the loudest people around, and if you want confirmation open your eyes and check if they’re wearing white sneakers.
My grandfather was a Petty Officer in the Navy in the Pacific in World War II. He never made it to Chief Petty Officer, to his great annoyance, but he learned not long after he arrived in the Marshall Islands that there were plenty of ways to get things done without having that rank. The story goes that in those days only Chiefs were issued toolboxes on the base, so if somebody carrying a toolbox asked you to come along and help with a project, you did. Grandpop discovered this and, not being one to be bound by Navy regulations, would just pick up a toolbox when he wanted to raise a crew for some task, and people would come along and help. Conversely, if he didn’t have a toolbox, no one was interested.
One of the things I like about working in open source, and at Red Hat specifically, is that you don’t need to be carrying a toolbox to get people interested in working with you on a task. All you really need is a good idea and some knowledge of who the people are who might want to help. I’m not sure why this should be so — maybe it is that so much of our work is in open source communities that are powered by volunteer effort, or maybe we just all believe we know enough to decide for ourselves whether we want to help with something. Either way, many of the best things we have done at Red Hat have come not from top-down decisions but from “coalitions of the inspired” getting together and pursuing something that looks worthwhile.
There are some drawbacks to this culture. It tends to put a strain on people who are willing to volunteer, because not everyone is — when I was in Brno, we had a lot of manager committees to look after the site, and it was always the same 20 managers who showed up to help (out of 100). It also makes it hard to know whether people are doing what they’re really supposed to be, or working on side projects they find interesting.
I am fairly sure, however, that I’d rather have it this way than the way I imagine things work at other large companies — doing just what’s required, and lots of politics. Plus I don’t see how I could carry a toolbox to all the meetings I go to.
I’m about to spend four days in a management offsite for Red Hat. This is the kind of thing I’m normally quite upbeat about, and I’m sure I will enjoy this one a lot as well. However I confess to some degree of cynicism, made worse by the fact that I have a ton of work to do having just returned from the BVI and I’m annoyed I’m going to fall further behind while spending three days in meetings.
One of the things that is amplifying my cynicism is a lot of talk leading up to this event about “Cascading The Strategy.” “Cascading” in this usage is a business-speak verb for “Define a strategy at the top and get all the managers to faithfully explain it to their staff, and so on through the whole organization.”
Unfortunately this word has for me — in a business context at least — a whole bunch of entirely negative connotations:
- A Cascade only flows one way. The second tier does not have any influence on what the first tier Cascades, and so on. This is not at all in accord with the way we run our business at Red Hat, where open (and high-volume!) feedback on everything is very much the norm.
- It reminds me of the infamous Waterfall Process, in which a “product” flows downhill through various stages until it finally reaches its users. Know what else flows downhill? Ask a plumber…
- It reminds me of sewers and the sewage treatment process itself, in which effluent often flows down a Cascade in order to aerate and purify it (see photo above).
I’m fairly sure that the folks who use this term aren’t thinking of these connotations at all, but rather something beautiful like this:
Even in this case, however, it’s important to keep in mind what happens to someone standing at the bottom of a 979-meter waterfall.