Do we really think we can just bolt some sort of “government 2.0 module” onto steam-era bureaucracies and magically bring them into the 21st Century?
Sure, our governments served us fairly well in the 20th Century, at least in the West. They beat the bad guys in WWII, brought us through the scary Cold War and delivered health and prosperity our grandparents would have found unimaginable.
Not to mention Windows ME.
But times are changing. We’re starting to notice that things don’t work as well as they used to. We’re spending taxpayers’ money bailing out economies only to have bankers suck out more bonuses anyway. Conferences intended to agree on Climate Change action produce… well… nothing concrete. Sydney’s suburban railway network is slower than in the 1920s!
Having invested so much time and money on these institutions, though, we’re reluctant to let them go.
This is the sunk cost fallacy.
Concorde is the classic example. Long after it must have been clear to the French and British governments that no-one was going to buy this aircraft, they continued investing in it simply because they’d already spent so much and didn’t want to lose those “sunk costs”. Yet those costs were gone, no matter what. To continue spending was irrational.
The same happened in the Vietnam War, where US President Lyndon Johnson kept committing thousands of troops after he’d realised the cause was hopeless and America could not win.
Afghanistan, anyone?
I’ve written before, in Risk, Fear and Paranoia: Perspective, People!, that change is being held back by, well, fear and paranoia. But this morning I stumbled across Umair Haque’s The Builders’ Manifesto. He’s got it in one.
20th century leadership is what’s stopping 21st century prosperity.
The textbook skills of the “leader”, which Haque lists as “persuasion, delegation, coalition” were the very specific skills needed to run the giant, industrial-era organisations.
Here’s the problem in a nutshell. What leaders “lead” are yesterday’s organisations. But yesterday’s organisations — from carmakers, to investment banks, to the healthcare system, to the energy industry, to the Senate itself — are broken. Today’s biggest human challenge isn’t leading broken organisations slightly better. It’s building better organisations in the first place. It isn’t about leadership: it’s about “buildership”, or what I often refer to as Constructivism.
Leadership is the art of becoming, well, a leader. Constructivism, in contrast, is the art of becoming a builder — of new institutions. Like artistic Constructivism rejected “art for art’s sake,” so economic Constructivism rejects leadership for the organisation’s sake — instead of for society’s.
Haque goes on to compare the 20th Century leader and the even older “boss” to his new Builder, starting with Barack Obama.
Keith Olbermann recently took Obama to task for “a lack of leadership”. Yet, on the contrary, Obama’s problem is that he’s too much of a leader — and not enough a Builder. He’s mastered the principles of leadership; the result is politics as usual, instead of political reform.
It’s worth reading Haque’s manifesto in full. But for now, here’s his Ten Principles of Constructivism (contrasted with principles of leadership).
- The boss drives group members; the leader coaches them. The Builder learns from them.
- The boss depends upon authority; the leader on good will. The Builder depends on good.
- The boss inspires fear; the leader inspires enthusiasm. The Builder is inspired — by changing the world.
- The boss says “Iâ€; the leader says “weâ€. The Builder says “all†— people, communities, and society.
- The boss assigns the task, the leader sets the pace. The Builder sees the outcome.
- The boss says, “Get there on time;†the leader gets there ahead of time. The Builder makes sure “getting there†matters.
- The boss fixes the blame for the breakdown; the leader fixes the breakdown. The Builder prevents the breakdown.
- The boss knows how; the leader shows how. The Builder shows why.
- The boss makes work a drudgery; the leader makes work a game. The Builder organises love, not work.
- The boss says, “Go;†the leader says, “Let’s go.†The Builder says: “come.â€
Over at Johnnie Moore’s Weblog, where I found Haque’s manifesto, commenter “q” says:
While I admire Umair for his perspective, I do not see Umair (or many others) providing any practical solution or guidance for leadership that is uniquely different than much of the other leadership “advice” out there.
I see a vision at the meta-level without any substantial & practical micro-level details. It needs to be put into some real-world context
I must admit I also find some of the Principles creepy. “Organise love, not work?” Yes, we must learn to love Big Brother. Ahem. And some of it seems just a bit too evangelical for my liking.
And yet…
Identifying the problem is a key first step, even if we don’t have the answers yet. And the problem here is that we’re still fiddling with the old gadgetry of governance instead of building new things.
[Photos: British Airways Concorde G-BOAC photographed by Ian Britton at Manchester Aviation Park, 2005. © FreeFoto.com, used under a Creative Commons BY-NC-ND 3.0 license. Umair Haque via Harvard Business Review.]
Ironically, some middle managers of ye olde had these very qualities, including one other that is kind of entailed within point number 8, but is deserving of at least a sub-point appearance: The Builder keeps the owners off the building site.
😉
@sylmobile: One of my first full-time jobs at age 21 was in the public service for what was then the Department of Aviation. This was before it was subsumed into the Transport Australia mega-department and well before airports and air traffic control were sold off to the private sector. I was, in essence, the personal assistant to the head of staff development.
Ray Jobling was his name, and I learned a lot from him.
We’d meet every morning at 10am, when I was to hand him three sets of files. One was for him to sign immediately, which he did before handing them straight back to me. Another was for him to read later and make a decision. The last was for us to discuss there and then, so I could take appropriate action immediately.
For both of the latter sets of files I must have already looked through everything and provided my own recommendation along with my reasoning.
“Don’t bring me problems,” he said. “Bring me decisions.”
I see “the Builder” in this scenario is someone who does not fit into the construct of Big Brother. They CAN’T be that far away from the work to be done. The Builder is in the trenches, not 3+ levels of people away from the actual things that need fixing. Critical team members who perhaps take guidance from a Leader type, but are generally autonomous and work with other builders/do-ers/workers/fix-er-up-ers.
That entire chart is a bit broad in scope though. I think most people reading it could point to specific examples of how each of those archetypes have fit into their world at one point or another, but it does not lend easily to being applied practically as archetypes to avoid or aspire to going forward.
Personally, I’d love to see some exercises in taking the Agile methodology of software building and applying that to governmental problem solving. I’ve only been properly introduced to it lately, but it seems like a really good framework for breaking things down into deliverable solutions faster.
@Giania: I don’t know Agile in detail but, yes, there are certainly new models for organising work which are not based on centralised control and top-down delegation.
These models do, however, assume a awful lot about the people taking part — that they’re self-directing and self-managing, able to seek out the work they need to do, and able to communicate openly across the organisation to anyone they need to contact.
The challenge in all this is that people have, in general, not been taught to think for themselves in this way, and organisations are not structured to support it. It’s OK for alpha geeks, but not for people whose working lives have consisted of following procedures written down by someone else and into which they’ve been trained.
That, of course, is the challenge.
@Stilgherrian Oh there’s definitely a learning curve involved, and not everybody is capable of adapting to new processes. (Those people should not be in office.) For us there’s still a lot of hand-holding and referring back to the process guidelines, and our leader, before making moves. The goal is not to say “here’s the framework, make sense? Good now you’re on your own” because that’s unreasonable to expect of anyone, no matter how alpha geek they may be. The goal is to interject a process of interactivity and working in smaller pieces into an otherwise completely wasteful cycle of dysfunction and epic failures. (At least in working with programmers, I’ve discovered that “too big to fail” is the exact opposite of the truth, the bigger something is, the more likely it is to fail. More moving parts equal more points of failure, etc.)
The goal with Agile, in very general terms, is to abolish the old model of the business (or people making a request in general) thinks for a really long time or no time at all about what they want, and throw a request over the wall into the development/execution/building tank. In this old model, the dev team then works for as long as it takes to get to the final deliverable outlined by original large/vague request, never really communicating with any one on the requesters’ side, then deliver something at the end that may be completely thrown away, already out of date, not what was asked for after all, etc.
The Agile methodology employs point persons, outside of the work team (or on the work team if they have time to spare), to coordinate with the requesting side as the idea is getting closer to having actual action items emerge from the concept. (Should be able to do this madlib for your idea: As a _type of person_ I want to _accomplish this goal_ so I can _provide some value_.) This balances the responsibility of making sure that things go into development correctly on the business who (should) know what goals they want to accomplish, and the developers who actually have to do the work to create what’s being asked for. These talks have multiple purposes: getting clarifications early in the process, getting the business side acquainted with the amount of work development really does so they can formulate their requests better to start with, negotiating to break apart an “epic” or large scale idea into smaller deliverables.
That last bit is sort of the key. The builders and the thinkers, sitting down and saying “What is the smallest thing I can do right now that will provide value?” Breaking it down to, and doing that one small thing will, in fact, provide value on its own, as well as getting a step closer to completing the Big Picture Idea. And if the Big Picture Idea has to change, or is canceled, that one small thing may still be viable as-is. Or if it’s not, it’s easier to remove or change one small thing than it is one very large thing.
Progress requires us to change our attitudes, our way of working and thinking about work. Again I submit that if the current people who are in office or interested in being part of the political machine aren’t willing to learn new tricks (any new tricks, mind you, not just this one I’ve discussed here), then they aren’t worth keeping. Keep in mind also, that there are a lot of software groups that are having to learn Agile, having to be trained out of previously written procedures or worse having to be trained out of old habits and attitudes toward work. Some people adapt and some people don’t. It’s not even that easy for geeks, because it requires them to interface directly with actual living humans who are not also part machine.
That got a lot windier than I’d intended, but I feel like I didn’t make my ideas very clear before and wanted to remedy that. I also get particularly passionate when it comes to learning new things. EVERYONE (not just geeky types) should be learning something new, all the time. It doesn’t stop with formal education and few things infuriate me more than people who refuse to learn.