Financial Cryptography

Elinor Ostrom's 8 Principles for Managing A Commmons

(Editor's note: Originally published at http://www.onthecommons.org/magazine/elinor-ostroms-8-principles-managing-commmons by Jay Walljasper in 2011)

Elinor Ostrom shared the Nobel Prize in Economics in 2009 for her lifetime of scholarly work investigating how communities succeed or fail at managing common pool (finite) resources such as grazing land, forests and irrigation waters. On the Commons is co-sponsor of a Commons Festival at Augsburg College in Minneapolis October 7-8 where she will speak. (See accompanying sidebar for details.)

Ostrom, a political scientist at Indiana University, received the Nobel Prize for her research proving the importance of the commons around the world. Her work investigating how communities co-operate to share resources drives to the heart of debates today about resource use, the public sphere and the future of the planet. She is the first woman to be awarded the Nobel in Economics.

Ostrom’s achievement effectively answers popular theories about the "Tragedy of the Commons", which has been interpreted to mean that private property is the only means of protecting finite resources from ruin or depletion. She has documented in many places around the world how communities devise ways to govern the commons to assure its survival for their needs and future generations.

A classic example of this was her field research in a Swiss village where farmers tend private plots for crops but share a communal meadow to graze their cows. While this would appear a perfect model to prove the tragedy-of-the-commons theory, Ostrom discovered that in reality there were no problems with overgrazing. That is because of a common agreement among villagers that one is allowed to graze more cows on the meadow than they can care for over the winter—a rule that dates back to 1517. Ostrom has documented similar effective examples of "governing the commons" in her research in Kenya, Guatemala, Nepal, Turkey, and Los Angeles.

Based on her extensive work, Ostrom offers 8 principles for how commons can be governed sustainably and equitably in a community.

8 Principles for Managing a Commons

1. Define clear group boundaries.

2. Match rules governing use of common goods to local needs and conditions.

3. Ensure that those affected by the rules can participate in modifying the rules.

4. Make sure the rule-making rights of community members are respected by outside authorities.

5. Develop a system, carried out by community members, for monitoring members’ behavior.

6. Use graduated sanctions for rule violators.

7. Provide accessible, low-cost means for dispute resolution.

8. Build responsibility for governing the common resource in nested tiers from the lowest level up to the entire interconnected system.

HR is broken - the recruiter honeypot

It is an old claim of mine that the employment business is broken. Not broken in the sense of cryptography -- down from 256 bits of strength to 255, the horror! -- but broken in the human, social sense. ROT13 broken. A complete facade, a level of reliability that even bankers would find troubling.

To prove this total brokenness, here's some great informal research with some awful findings.

The Recruiting Crisis

In late 2009, my desk was piled with JavaScript resumes. Our homegrown JavaScript framework edged us over competitors but maintaining our technical advantage meant carefully crafting a lean, delta-force Web team. Though I averaged two interviews a day, we had only grown the team by three-four engineers each year.

However, in 2010, that had to change. It was our first year with a real revenue target and also the first time we planned to pivot from our original IM product. We charted our end-of-year goals, quarterly milestones, and eventually backtracked to our team and hiring priorities. To meet our 2010 goals, I needed to double the JavaScript team in just one quarter. If I didn't, innovation would stall and without revenue, our business would be in serious jeopardy.

To summarise, a founder of a startup got frustrated with recruiting Javascript programmers, and in one mad regrettable night, created a false identity as the very image of the geekly god of code she wanted to employ. She then watched what the recruiters did with the perhaps noble intention that she would employ the best of those very recruiters to help her.

Didn't quite work out that way. Here's her findings in a nutshell:

• LinkedIn is the *only* channel for recruiters! Anything else was worthless for garnering their attention. Only LinkedIn got attention from recruiters. While great for LinkedIn's stock holders, it is a sad sickening result in and of itself; it evidences a monocultural blindness that bespeaks of disaster for the employment business.
• Her own company did not use LinkedIn. They had recruited a great team by all sorts of other methods. Which matches what I recommended a while back: when you discover a trend, do the reverse.
• All the recruiting approaches were the same. There were mild differences between the general categories of Large & Startup, but within those archtypes, the approaches were cut & paste. Best Practices has become Monoculture has taken root with a vengeance.
• Every recruiter she had used in the past broke the contract. There was no love lost with recruiters' clients, they all tried to poach her false god of code. This is the endgame in a broken employment market, "I poach because I can't think (of anything better)"
• Every recruiter used white lies such as "I've been referred to you by ..."
• Who was best at recruiting? The ordinary manager with no recruiting experience, training or bias.
• Finally, out of 382 recruiters, only one checked the facts and tried to get a real contact with the person. And found out the person didn't exist! So when you think you are paying these people for reliable information, you are deceived. Recruiters provide no checking on anything, in general.

That's the quick read. If however you are a company founder interested in recruiting, you should definitely read the entire thing. It's off the wall, very counter-cultural. But that's what it takes to defeat a monocultural failure -- fresh approach.

How to make scientifically verifiable randomness to generate EC curves -- the Hamlet variation on CAcert's root ceremony

It occurs to me that we could modify the CAcert process of verifiably creating random seeds to make it also scientifically verifiable, after the event. (See last post if this makes no sense.)

Instead of bringing a non-deterministic scheme, each participant could bring a deterministic scheme which is hitherto secret. E.g., instead of me using my laptop's webcam, I could use a Guttenberg copy of Hamlet, which I first declare in the event itself.

Another participant could use Treasure Island, a third could use Cien años de soledad.

As nobody knew what each other participate was going to declare, and the honest players amongst did a best-efforts guess on a new statically consistent tome, we can be sure that if there is at least one honest non-conspiring party, then the result is random.

And now verifiable post facto because we know the inputs.

Does this work? Does it meet all the requirements? I'm not sure because I haven't had time to think about it. Thoughts?

(B) The Business Choice of making a Business Investment in Bitcoin (part B of ABC)

Last month, I launched a rocket at those who invest in Bitcoin as the Coin or the Currency. It's bad, but I won't repeat the arguments against it.

For those of you who've survived the onslaught on your sensitivities, and are genuinely interested in how to make an investment into the cryptocurrency world, here is part B: the Business! The good news is that it is shorter.

---

If one was to look for a good Bitcoin investment in a business, what would it be? I think you should be asking questions like these:

• The business in question has a regulatory model. It doesn't need to be right or sustainable, more that the business owners just need to understand the word. That's because, whether they know it or not, the word is coming for them one day.
• hey have a governance model. Ditto.
• You as investor understand the difference. This is where it gets messy. Most people think the above two terms are the same thing, but they are not. A regulatory model is imposed by a regulator, and is mostly about compliance with something that protects others such as the regulator or their flock (banks). Whereas a governance model is imposed by yourself, over your own operations, to protect your assets and the assets of the customer. Completely different, and completely misunderstood in the eyes of the external stakeholder community. Therefore, likely misaligned in the eyes of the Bitcoin CEO. Do you see where this is going?
• They have a Sean Parker. By this, I mean the person with real experience of this broad Internet / money / social networking business space, the guy who's been there twice before, and this time, *he's there* at the critical juncture to that 2 kids and a fridge full of beer all the way to a big business. See the Facebook movie if this doesn't make any sense.

---

Signs of a bad investment:

• Wanting to be the next big exchange.
• No relevant experience in the chosen direct business model. This is distinct from the Sean Parker point above. By this I mean, if wanting to do an exchange, the people have / do not have (select one) prior experience in what a daily trading model is, what 5PM is, what governance is, what an internet security model is. E.g., Mt Gox, which traded without understanding any of these things.
• Belief that tech solves all problems.
• No knowledge of what came before the Bitcoin paper.
• Deal hinges in part on banks or regulators. For example, these guys are DITW:

  Part of laying the groundwork is bringing the establishment on board, Malka said. “We need more banks participating in this. We need regulators. I’m part of the Bitcoin Foundation – we are out there trying to educate regulators.” Getting regulators on board will help get the banks to come along, Liew predicted. “If the regulators explicitly set forth rules that say, ‘Bright line, do this, you will find a bank that is willing to take on bitcoin customers,’” Liew said.

---

That's my B list so far. You'll note that it includes no conventional things, because you already have those. All it includes is pointers to the myths-of-doom peddled in the current bitcoin world as business talk. It's designed to separate out the happy hopefuls from the actual business possibilities, in a world where talking is deeper than walking.

Next up, when I get to it, is my A list: a point I believe so important I saved it for another post. Watch this space.

The IETF's Security Area post-NSA - what is the systemic problem?

In the light of yesterday's newly revealed attack by the NSA on Internet standards, what are the systemic problems here, if any?

I think we can question the way the IETF is approaching security. It has taken a lot of thinking on my part to identify the flaw(s), and not a few rants, with many and aggressive defences and counterattacks from defenders of the faith. Where I am thinking today is this:

First the good news. The IETF's Working Group concept is far better at developing general standards than anything we've seen so far (by this I mean ISO, national committees, industry cartels and whathaveyou). However, it still suffers from two shortfalls.

1. the Working Group system is more or less easily captured by the players with the largest budget. If one views standards as the property of the largest players, then this is not a problem. If OTOH one views the Internet as a shared resource of billions, designed to serve those billions back for their efforts, the WG method is a recipe for disenfranchisement. Perhaps apropos, spotted on the TLS list by Peter Gutmann:

Documenting use cases is an unnecessary distraction from doing actual work. You'll note that our charter does not say "enumerate applications that want to use TLS".

I think reasonable people can debate and disagree on the question of whether the WG model disenfranchises the users, because even though a a company can out-manouver the open Internet through sheer persistence and money, we can still see it happen. In this, IETF stands in violent sunlight compared to that travesty of mouldy dark closets, CABForum, which shut users out while industry insiders prepared the base documents in secrecy.

I'll take the IETF any day, except when...

2. the Working Group system is less able to defend itself from a byzantine attack. By this I mean the security concept of an attack from someone who doesn't follow the rules, and breaks them in ways meant to break your model and assumptions. We can suspect byzantium disclosures in the fingered ID:

The United States Department of Defense has requested a TLS mode which allows the use of longer public randomness values for use with high security level cipher suites like those specified in Suite B [I-D.rescorla-tls-suiteb]. The rationale for this as stated by DoD is that the public randomness for each side should be at least twice as long as the security level for cryptographic parity, which makes the 224 bits of randomness provided by the current TLS random values insufficient.

Assuming the story as told so far, the US DoD should have added "and our friends at the NSA asked us to do this so they could crack your infected TLS wide open in real time."

Such byzantine behaviour maybe isn't a problem when the industry players are for example subject to open observation, as best behaviour can be forced, and honesty at some level is necessary for long term reputation. But it likely is a problem where the attacker is accustomed to that other world: lies, deception, fraud, extortion or any of a number of other tricks which are the tools of trade of the spies.

Which points directly at the NSA. Spooks being spooks, every spy novel you've ever read will attest to the deception and rule breaking. So where is this a problem? Well, only in the one area where they are interested in: security.

Which is irony itself as security is the field where byzantine behaviour is our meat and drink. Would the Working Group concept past muster in an IETF security WG? Whether it does or no depends on whether you think it can defend against the byzantine attack. Likely it will pass-by-fiat because of the loyalty of those involved, I have been one of those WG stalwarts for a period, so I do see the dilemma. But in the cold hard light of sunlight, who is comfortable supporting a WG that is assisted by NSA employees who will apply all available SIGINT and HUMINT capabilities?

Can we agree or disagree on this? Is there room for reasonable debate amongst peers? I refer you now to these words:

On September 5, 2013, the New York Times [18], the Guardian [2] and ProPublica [12] reported the existence of a secret National Security Agency SIGINT Enabling Project with the mission to “actively [engage] the US and foreign IT industries to covertly influence and/or overtly leverage their commercial products’ designs.” The revealed source documents describe a US $250 million/year program designed to “make [systems] exploitable through SIGINT collection” by inserting vulnerabilities, collecting target network data, and influencing policies, standards and specifications for commercial public key technologies. Named targets include protocols for “TLS/SSL, https (e.g. webmail), SSH, encrypted chat, VPNs and encrypted VOIP.”
The documents also make specific reference to a set of pseudorandom number generator (PRNG) algorithms adopted as part of the National Institute of Standards and Technology (NIST) Special Publication 800-90 [17] in 2006, and also standardized as part of ISO 18031 [11]. These standards include an algorithm called the Dual Elliptic Curve Deterministic Random Bit Generator (Dual EC). As a result of these revelations, NIST reopened the public comment period for SP 800-90.

And as previously written here. The NSA has conducted a long term programme to breach the standards-based crypto of the net.

As evidence of this claim, we now have *two attacks*, being clear attempts to trash the security of TLS and freinds, and we have their own admission of intent to breach. In their own words. There is no shortage of circumstantial evidence that NSA people have pushed, steered, nudged the WGs to make bad decisions.

I therefore suggest we have the evidence to take to a jury. Obviously we won't be allowed to do that, so we have to do the next best thing: use our collective wisdom and make the call in the public court of Internet opinion.

My vote is -- guilty.

One single piece of evidence wasn't enough. Two was enough to believe, but alternate explanations sounded plausible to some. But we now have three solid bodies of evidence. Redundancy. Triangulation. Conclusion. Guilty.

Where it leaves us is in difficulties. We can try and avoid all this stuff by e.g., avoiding American crypto, but it is a bit broader that that. Yes, they attacked and broke some elements of American crypto (and you know what I'm expecting to fall next.). But they also broke the standards process, and that had even more effect on the world.

It has to be said that the IETF security area is now under a cloud. Not only do they need to analyse things back in time to see where it went wrong, but they also need some concept to stop it happening in the future.

The first step however is to actually see the clouds, and admit that rain might be coming soon. May the security AD live in interesting times, borrow my umbrella?

Research on Trust -- the numbers matter

Many systems are built on existing trust relationships, and understanding these is often key to their long term success or failure. For example, the turmoil between OpenPGP and x509/PKI can often be explained by reference to their trust assumptions, by comparing the web-of-trust model (trust each other) to the hierarchical CA model (trust mozilla/microsoft/google...).

In informal money systems such as LETS, barter circles and community currencies, it has often seemed to me that these things work well, or would work well, if they could leverage local trust relationships. But there is a limit.

To express that limit, I used to say that LETS would work well up to maybe 100 people. Beyond that number, fraud will start to undermine the system. To put a finer point on it, I claimed that beyond 1000 people, any system will require an FC approach of some form or other.

Now comes some research that confirms some sense of this intuition, below. I'm not commenting directly on it as yet, because I haven't the time to do more than post it. And I haven't read the paper...

---

'Money reduces trust' in small groups, study shows
By Melissa Hogenboom Science reporter, BBC News

People were more generous when there was no economic incentive

A new study sheds light on how money affects human behaviour.

Exchanging goods for currency is an age old trusted system for trade. In large groups it fosters co-operation as each party has a measurable payoff.

But within small groups a team found that introducing an incentive makes people less likely to share than they did before. In essence, even an artificial currency reduced their natural generosity.

The study is published in journal PNAS.

When money becomes involved, group dynamics have been known to change. Scientists have now found that even tokens with no monetary value completely changed the way in which people helped each other.

Gabriele Camera of Chapman University, US, who led the study, said that he wanted to investigate co-operation in large societies of strangers, where it is less likely for individuals to help others than in tight-knit communities.

The team devised an experiment where subjects in small and large groups had the option to give gifts in exchange for tokens.

The study

• Participants of between two to 32 individuals were able to help anonymous counterparts by giving them a gift, based solely on trust that the good deed would be returned by another stranger in the future
• In this setting small groups were more likely to help each other than the larger groups
• In the next setting, a token was added as an incentive to exchange goods. The token had no cash value
• Larger groups were more likely to help each other when tokens had been added, but the previous generosity of smaller groups suffered

Social cost

They found that there was a social cost to introducing this incentive. When all tokens were "spent", a potential gift-giver was less likely to help than they had been in a setting where tokens had not yet been introduced.

The same effect was found in smaller groups, who were less generous when there was the option of receiving a token.

"Subjects basically latched on to monetary exchange, and stopped helping unless they received immediate compensation in a form of an intrinsically worthless object [a token].

"Using money does help large societies to achieve larger levels of co-operation than smaller societies, but it does so at a cost of displacing normal of voluntary help that is the bread and butter of smaller societies, in which everyone knows each other," said Prof Camera.

But he said that this negative result was not found in larger anonymous groups of 32, instead co-operation increased with the use of tokens.

"This is exciting because we introduced something that adds nothing to the economy, but it helped participants converge on a behaviour that is more trustworthy."

He added that the study reflected monetary exchange in daily life: "Global interaction expands the set of trade opportunities, but it dilutes the level of information about others' past behaviour. In this sense, one can view tokens in our experiment as a parable for global monetary exchange."

'Self interest'

Sam Bowles, of the Santa Fe Institute, US, who was not involved with the study, specialises in evolutionary co-operation.

He commented that co-operation among self-interested people will always occur on a vast scale when "helping another" consists of exchanging a commodity that can be bought or sold with tokens, for example a shirt.

"The really interesting finding in the study is that tokens change the behavioural foundations of co-operation, from generosity in the absence of the tokens, to self-interest when tokens are present."

"It's striking that once tokens become available, people generally do not help others except in return for a token."

He told BBC news that it was evidence for an already observed phenomenon called "motivational crowding out, where paying an individual to do a task which they had already planned to do free of charge, could lead people to do this less".

However, Prof Bowles said that "most of the goods and services that we need that make our lives possible and beautiful are not like shirts".

"For these things, exchanging tokens could never work, which is why humans would never have become the co-operative species we are unless we had developed ethical and other regarding preferences."

google's oddball questions (3) How to break out of the worst of HR's best practices (part 3 of 3 part rant)

I recently introduced a hypothesis to explain recruiting (I and II). My basic point is that the art has sunk to a deplorable target of /people like us/. Here's another snippet of evidence from Forbes, but the stuff abounds:

1. Can you do the job?
2. Will you love the job?
3. Can we tolerate working with you?

So what do real HR people do? Let's take a best practices recruiting strategy from a best of breed company as described by a leading HR-oriented publisher:

A few more tweaks of the dial and Colton had specified what current jobs these people should be holding, how many years of experience they should have and their locations.

and reduce it to its essence: Poaching. I poach because I can't think (of anything better). Ergo, the only signal that matters in recruiting is this: is the copy person doing a copy job at a copy company?

In order to establish this point a little more scientifically is tough, but it can be done by an inductive argument:

In fact, there's been quite a bit of research on the topic. [snip] Unfortunately, the human-resources profession has yet to identify a widely accepted alternative. But it's hardly been from lack of trying. Some companies have used "biodata" (a mash-up of the words biography and data). In World War II, it was found that promising pilots could be identified with a simple question: "Did you ever build a model airplane that flew?" In the 1950s, the emerging computer industry latched onto logic puzzles as an attempt, however makeshift, to identify those capable of thinking in new ways.

Does the puzzle approach popularized by the tech industry work? A controlled experiment is difficult - you would have to ask a lot of applicants the same question, record the results and then hire them all.

(my emphasis) Exactly. Let's take the last point first: there is no control group in the experiment. So, there is no experiment. All data is therefore meaningless because it isn't compared to anything worth comparing to, except itself.

Which leads us to see Spence's "Job Market Signalling," a seminal article that formed the third leg of the economics school of imperfect information. This paper suggests that, in the absence of causality, such data can generate a stable feedback loop, even when it has nothing to do with the measured quality.

In other words, if one is using techniques that have no scientific, controlled and measurable foundation, then the results from these differing techniques are scientifically indistinguishable -- in having no basis in experimental method. Further, Spence suggests, in the absence of good science, many such unfounded signals are likely to reach stability within a feedback loop of approval, whether they are good, bad or indifferent to the desired result.

Therefore, asking questions about nickels and human poverty is entirely as acceptable as asking teasers about garbage collection strategies. None of them predict anything, and therefore are all equally likely to appear to be as good as each other.

Which, in practical HR market terms, leads to successive waves of obsession over the latest fad technique of unmeasurable quality. We copy what others are doing, because copying others stops us being fired. Last year, brain teasers. This year, poaching. Next year?

In short: GIGO which stands for Garbage In, Garbage Out.

To address the Spencarian inductive argument from the point of Year 0: these techniques once worked. Yes, pilots did self-select themselves by playing with model aircraft, to a small extent. Yes, and you'll see that the same technique worked in the very early stages of growth in the IT field. Before any information existed even the most simplistic test could have an effect. But factor in a few years of information sharing, and the bounty of naïveté disappears. Competition leads to copycat behaviour on the other side of the desk: Everyone who wants to become a pilot then makes a model aircraft, anyone who wants to be a guru installs Linux. Everyone knows computer people are supposed to be good at logic, and pilots are supposed to play with airplanes. Everyone knows google asks oddball questions. Beyond that?

Drop it, move on. Indeed, google, long-suffering foil for my 3-part rant, even google knows that asking oddball questions doesn't work. So says Laszlo Bock, SVP and chief operator of the geople:

On the hiring side, we found that brainteasers are a complete waste of time. How many golf balls can you fit into an airplane? How many gas stations in Manhattan? A complete waste of time. They don't predict anything. They serve primarily to make the interviewer feel smart.

What then can a poor recruiter do?

The first step along this journey is just knowing it: to realise that, if the field of Human Resources is a mess, you don't need to be much better than awful to do better. This is good news! The bar in recruiting is set somewhere close to shoe level so leaping it just requires thought, intent and vision.

The remainder of this rant, and series of posts, is really just that: Vision of the Barriers, as described. Then, Thinking, from that foundation so far laid out. Intent, I leave to you.

Onwards. A couple of barriers from the Economist:

There are two related problems to consider, says Mr Ben-Hur. One is that the "traditional talent deal" is no longer reliable: companies cannot invest in training for their more promising employees and expect to recoup the benefits for a decade.

Oops. Another sacred cow profaned and spoiled by the infidel. Yes, so-called training doesn't work without thought, but that's a rant for another day. Meanwhile...

The other is that firms looking for talent tend to overvalue external candidates and undervalue internal ones. Taken together, the two trends make a sort of sense: an internal candidate may be ready to jump ship; one coming in from outside should be grateful for the job for a couple years at least. But imagining the most talented employees as fish only briefly caught makes it hard for companies to recognise, much less reward, their best performers.

Which leads to a thoughtful suggestion: It is a truism that your biggest asset is your own people. Hence, tip #1:

(1) Ask your people

But the trick here is not to ask them how to employ their friends (a.k.a., people like us) but how to employ their betters. Ask your people how they would employ someone better than themselves? How would they employ the person who would put them out of a job?

As we have seen, there exist pernicious biases that lead organisations to pursue monoculture as if it is a good thing, and refine the concept to include it as a job requirement. For example, I know one organisation that insists that all its job interviewees use its own defined format for answering questions (called STAR if anyone needs a tip to steer clear of that particular monoculture). The format is presented as a convenient recruiting communications framework, so it helps the recruiter. But, as the format is of no use in actual productivity, is encouraged learning for insiders, and is highly spoofable, it amounts to a barrier to entry, a restraint on trade and an encouragement to dishonesty; but worse than that, no matter that HR experts have presumably anointed it from on high, it acts to homogonise the organisation in a way that is almost impossible to break out of.

Which leads to the second point:

(2) search out biases and eliminate them

To some extent, this has to be done carefully. If you can't see why the bias is hurting you, and how to address the root causes, don't go there. But there are some easy biases to see, and just thinking about them can get you on the right track. Diversity helps at a conceptual level, therefore think about that:

• Employ all nationalities *except your own* and/or the dominant one in your organisation.


• Employ women, if your industry is dominated by men. Or, employ men if it's a woman-dominated field.


• If you see a wall of grads in your firm, employ some non-graduates!

By now, we should be ready to appreciate that all 'systems' and practices are subject to dramatic weaknesses. So how does one actually learn about someone, once your flawed system has popped up a name?

If we accept that the CV+interview process is dead, then conducting more interviews, as they enjoy doing in banking, isn't going to help.

There is only one real way, and that is to work with the person. Which leads to the chicken & egg problem -- you can't employ people before you've worked with them, and you can't work with people before you've employed them.

To get out of the repetitive tedium of monocellular evolution, one needs to take some risks. Design your employment practices to incorporate these risks and use them as opportunities. In essence, this means

(3) short term engagements

Instead of aspiring to a goal of lifelong employment, realise our world is really about short term engagements in a volatile world. Whether you like it or not, the long term loyal employee is now a novelty.

"More companies now prefer to try an employee out as a contractor, with the possibility of hiring them full-time." Job seekers should be open to various forms of compensation.

(link lost) Do that, and learn. Look at all the ways you can bring a person in on a short term opportunity to find out, really, whether this person works: contracts, of course. Also bit-piece work, consulting, internships. Further, consider competitions, hackathons, outreach teaching. Open source teams. Get it? Google's summer of code is a recruiting technique.

Finally, how do we develop a system that doesn't suffer from all the ills of all of the systems you read in all of those over-priced HR magazines? Let's take a hint from the diversity concept (don't employ university graduates) and broad it:

(4) Do exactly the opposite of what the rest of the world does

How can this be right? Easy, and here's the proof: if these posts have shown anything, it is that the current practices are approximately worthless. Therefore, if the current practices are worthless, and people keep doing them, they are dividing the space into two pools, separated on success/failure over false signals. Because the measurement is worthless, there is likely the same amount of talent, randomly, in one pool as there is in the other.

The only difference is that one pool of talent is contested, while the other is uncontested!

Choose the uncontested pool of talent. Not only does this make it easier because you're the only one swimming in it, but the price of entrance is also much lower. The other pool is being driven up in price, while your pool is being driven down.

How do we turn the 'uncontested markets' strategy into practical techniques to build high ROI teams? Apply some thought about what everyone does -- that's easy because up until now you've likely been copying them -- and simply reverse it. I'll leave a specific list to a later appendix.

I'll close with this one thought, by way of a caveat: the careful reader will note that google does dabble in most of these ideas, in one means or another. So not withstanding their use herein as a foil for baddest best practices, they may actually be leaders in better practices as well.

Copy at least this from them: Don't be afraid to try things out, and to admit mistakes. And watch the movie Being John Malkovich if only to figure out the screenshots herein...

Can you think out of the blender? and other oddball questions (Part 2)

A month or so ago, I asked about oddball questions in job interviews. Some are related to job function but some are challengingly perverse. If you are, like me, disturbingly offended by a dark and fearful force within those questions, then it is to you I address this rant in three parts (I, II, III)

Where are these oddball interview questions coming from? Why are they so deliciously amusing yet so dangerous and so ... off-mission? I hope to clarify this in today's rant, but before that, a word of warning -- if you are in the HR industry, you will not be happy. If you are proud of your company's achievements in recruiting, you might be happier reading elsewhere. That warning given, press on!

Why do companies ask oddball questions in recruiting questions? And why does our ever-suffering foil, google, lead the world in this?

It's not because the employers are dumb, as indeed their strategy (and this goes for all high tech players) is often to find the smartest of the smart. So they ask smart questions. OK, I'll pay that as signal at least. Let's present another foil:

* "You are shrunk to the height of a nickel and thrown into a blender. Your mass is reduced so that your density is the same as usual. The blades start moving in 60 seconds. What do you do?"

Yeah. So, physics or biology or again, simply just brain teasers. What the questioner is trying to do is figure out if you are smart. Or at the minimum, whether you can whiteboard, draw in different ideas, whether you can think out of the blender, so to speak.

But, if they can truly do that, then they're onto something rather extraordinary. The world has been researching the alchemy of intelligence for a long long time. We've got IQ, EQ, psychometrics, Myers-Briggs, and a whole host of other things. None of them necessarily work to figure out if anyone is smart. Indeed, apparently, this is admitted:

"We'll get to the longer answer, but the short answer is that Google isn't looking for the smartest, or even the most technically capable, candidates. Google is looking for the candidates who will best fit Google."

Right. Thank you. Indeed, their HR mission bears repeating:

"Google is looking for the candidates who will best fit Google."

And who are they? That's a question akin to asking who's smart -- Alchemy! Let's employ occam's razor here and say it bluntly: people like the people who are already there. Look at this page and you'll see that there is an obsession with basic computer algorithms. So, if the founders liked brain teasers, then brain teasers they ask. If they liked economic problems such as "solve world hunger" then that's what is asked. Google's founders were academics in Computer Science, so they ask deep questions that are taught in CS school and recorded in Knuth. Etc.

In short, the HR mission of choice is:

People like us.

This is not really a new thing, indeed it could almost be considered best practice in hiring. The Economist distills an entire book entitled What It Takes: Seven Secrets of Success from the World's Greatest Professional Firms by Charles Ellis down to one line:

Above all, these firms are fanatical about recruiting new employees who are not just the most talented but also the best suited to a particular corporate culture .

The only problem is, this strategy has to be the greatest failing of any company... Indeed this is also known, in a perverse sense:

4. Only hire people who like you or think like you. Flattery feels good, but it doesn't pay the bills....

We can say it another way: /monoculture/. The good thing about the term of art /monoculture/ is that tech companies actually know what that means, courtesy of a famous or infamous paper by Dan Geer & friends entitled "CyberInsecurity: The Cost of Monopoly." It was famous because history proved it to be true, as it correctly identified the seeds of Microsoft's fall from grace; it was infamous because the lead author got fired within 24 hours for daring to question the powers that were.

Monoculture in hiring is pernicious because it is so attractive: I don't know how to find the best people because I don't understand the question, but I'm one of the best, so I'll just one look for people like me. Works for me.

The strategy sounds entirely logical, but it is based on several false assumptions. Let me rant a bit: For a start, there is research out there that suggests that people routinely rate themselves higher than others do. Geer et al suggests that diversity is better than monoculture for survival in an aggressive world, and wider research backs that up. Indeed, Belbin says diversity is critical for success, suggesting teams of 4 people minimum with 8 opposing roles. It's been known since 1980s (? Ed Yourdan?) that productivity varies as much as 20-fold. Mark Zuckerberg said somewhere it was a 100-fold difference. I'd say even a ratio is a hopeful figure because the difference between nothing and success in programming is far more than 20-fold. Divide 1 by 0 to see what I mean, I personally have suffered with programmers who could not do the job at all, and the result was zero, and often into the negative numbers if we add in indirect costs. Yet, for reasons that aren't easily explained today, we cannot easily apply the Star effect to the discipline of computing (tantalising clue), so the normal industry response fails. I could go on with what I know, but I can't easily cite the papers, and they're never checked anyway, so I'll stop here. End of rant.

Back to the subject, which is why the oddball question technique is so troubling: asking and answering smart questions may be a signal for productivity, but I'd reckon it's a false signal. Indeed, I'd suspect it is somewhat reversed. Really productive people don't have time for brain-teasers, whereas really unproductive people are surprisingly good at copying the signals of success. To succeed in an interview, you have to think quickly, but to succeed in productivity, you want to thing slowly -- the really difficult issues take some time to unravel.

So what happens when we run the reversely-correlated signal of /be like us/ up the flagpole? The Economist says:

In the past Mr Ellis would have praised Arthur Andersen, an audit firm that went bust in 2002 after getting embroiled in the collapse of Enron, a client. But the seeds of Andersen's demise were sown decades before, when the firm started to put its professional obligations to its clients second to the ambitions of its partners. Goldman began committing similar sins in the 1990s as its then leaders started to dream of awarding themselves fortunes by taking the firm public.

Echoes of Microsoft. The strategy works -- we ask for a lot of people like us. And we get them! I'll posit that this result is rational, expected and inevitable: copying the behaviour of rich partners of famous firms is somewhat easier than placing ones obligation to ones customers. Indeed, I'd lay good money on it: the job interview process is a race track of people to copy:

Each McKinsey applicant can be interviewed eight times before being offered a job; at Goldman, twice that is not unheard of. At Capital a serious candidate is likely to be seen by 20 people, some more than once.

Yet whoever heard of a customer at an interview? It's easy enough to meet people in bars, indeed we've even got a name for it: networking. But how do I get to meet McKinsey's clients? Google's customers? What's the name for showing you can meet your client's expectations? I don't have one on the tip of my toungue, do you? Certainly, there isn't a word as familiar as /networking/ or "pretending to be like you."

So what's really going on here?

The deep, dark secret of human resources is that traditional job interviews don't work very well.

Thank you WSJ. This is the big picture, actually written a bit too narrowly. Traditional HR doesn't work well at all. Job interviews included. Indeed, all of the recruitment process looks like a shoe-in for Spence's Market Signaling syndrome where signals can be pursued as essential, and have zero relevance to the business. With stability, but more on that later.

Not convinced? Let's consider more tantalising evidence from the external recruiting angle. If the company itself has no better signal than /people like us/ what then does the headhunter do? The evidence suggests that the process is best labelled as Star Gazing:

The study's "gaze tracking" technology showed that recruiters spent almost 80% of their resume review time on the following data points:

* Name
* Current title/company
* Current position start and end dates
* Previous title/company
* Previous position start and end dates
* Education

See what recruiters are looking at? What another company looks at. In short, if you're employed at a competitor, you're golden. If not, you're dead. Which is pretty convincing evidence that the most important thought a recruiter has is not his own client (nor his client's client) but the thoughts of a close competitor!

More on star gazing:

The best time to contact a headhunter is when you are employed.

"Headhunters don't typically work with job candidates that are unemployed," says Terri Lee Ryan, a career coach and author.

"Companies don't pay them big money to present workers that aren't gainfully employed. In this market there are many good workers on the sidelines, yet companies still want to see candidates that are gainfully employed and on the 'top of their game.' This is why I tell workers to never quit their job until they have a new one."

"These days, you never know if your job could disappear tomorrow," says Erik M. Tomasi, Chief Operating Officer of DTG Consulting Solutions Inc. "Anticipate the problem before it happens by networking and responding to headhunters, even when you're happy with your current job."

This suggests that your current employer is the primary signal that matters to the headhunter. Not you yourself, not the recruiter's client, and certainly not the client's client. This makes perfect sense if and only if the buying company has a strategy that only it can interpret, and cannot therefore explain it measurably to the recruiter, *and* if the recruiter cannot otherwise measure the quality of you, yourself. Check -- /people like us/ is almost by definition internally rich and vacuous to outsiders. Check -- techniques used are susceptible to copying and preparation.

In order to deal with this, the recruiter elevates the signal of competitor company to the top, and other things that don't deliver to the bottom.

Hence, /people like us/ leads to /companies like us/ which becomes the zero-sum game: we don't recruit, we poach. It's as if the ghost of IBM has come to haunt us -- nobody ever got fired for poaching (from IBM?)

Smart companies sometimes spot this and decline to enter the zero-sum game. Kudos to them. One controversial approach is the infamous no-poaching agreements. Another is smallprint notices on its websites to effect of "offers from headhunters will be plonked." A company may not be able to figure out the trap of /people like us/ but a smart company should be able to see the destructive pathetic lowest-common-denominator results of its sister strategy /companies like us/ .

What goes around, comes around. The late, great Steve Jobs was right in principle if not in method. To paraphrase his message, "You do business with me? No poaching the people you interact with in our partnership. I do constructive business with partners, not destructive business with opportunists."

In summary, we should now see why google leads the world in oddball questions. Google is a company chock full of people who like brain teasers, so they ask brain teasers in interviews. It does computer science at its core, a world full of oddball people. As the mix of CS and brain-teasers is impenetrable to other mere mortals, it appears to be the smartest of the smarts. On the outside, to the HR industry, at least. Who could see wrong in this?

However, the practice traces directly back to its HR mission of /people like us/ and is thus revealed as that humblest of concepts, best practices. Unfortunately, the so-called best practices are also a proof of mediocrity: if you cannot figure it out yourself, copy what others do. Like all best practices, it is a strategy that is weak enough for all to implement, more satisfying than doing nothing and allows you to talk loudly and confidently at the bar.

By asking the smartest CS brain teasers, google may appear to be the smartest company on the planet, but this is an accolade of Pyrrhic proportions to any firm that really cares.

What to do about this terrible state of affairs -- if one isn't Steve Jobs or Eric Schmidt or Mark Zuckerberg that is -- I'll leave to another post.

(This is part 2 of 3 parts: I, II, III)

google leads the world in ... oddball interview questions... ?!? (part 1 in a rant on searching for your HR mission)

Human Resources is one of those areas that seemed fatally closed to the geek world. Warning to reader: if you do not think Human Resources displays the highest volatility in ROI of any decision you can make, you're probably not going to want to read anything more of this rant. However, if you are bemused about oddball questions asked at interviews, maybe there is something here for you.

A rant in three parts (I, II, III).

Let's talk about google, which leads the world in infamous recruiting techniques. So much so that an entire industry of truthsayers, diviners and astrologers have sprung up around companies like it, in order to prepare willing victims with recipes of puzzlers, newts eyes and moon dances.

Why is this? Well, one of the memes in the press is about strange interview questions, and poking sly fun at google in the process:

• "Using only a four-minute hourglass and a seven-minute hourglass, measure exactly nine minutes--without the process taking longer than nine minutes,"
• "A man pushed his car to a hotel and lost his fortune. What happened?"

These oddball questions are all very cute and the sort of teasers we all love to play as children. More. But what do they have to do with google?

To be fair to them, it looks like google don't ask these questions at all and indeed may have banned them entirely but we need a foil to this topic, so let's play along as if they do spin some curveballs for the fun of it.

Let's answer the implied question of "what's the benefit?" by reference to other so-called oddball questions:

• "If Germans were the tallest people in the world, how would you prove it?" -- Asked at Hewlett-Packard, Product Marketing Manager candidate
• "Given 20 'destructible' light bulbs (which break at a certain height), and a building with 100 floors, how do you determine the height that the light bulbs break?" -- Asked at Qualcomm, Engineering candidate
• "How do you feel about those jokers at Congress?" -- Asked at Consolidated Electrical, Management Trainee candidate

The first one is straight marketing, understanding how to segment the buyers. The second is straight engineering, and indeed every computer scientist should know the answer: binary search. Third one? How to handle a loaded question.

So, all these have their explanation. Oddball questions might have merit. They are searching... but more than that, they are *directly related to the job*. But what about:

• "How would you cure world hunger?" -- Asked at Amazon.com, Software Developer candidate

A searching question, I'll grant! But this question has flaws. Other than discovering ones knowledge of modern economics (c.f., Yunis, de Soto) or politics or entrepreneurship or farming, how does it relate to ... software? Amazon? Retail markets? It doesn't, I'll say (and I'll leave what it does relate to, and how dangerous that is, as an exercise to the reader after having read all 3 posts).

Now back to google's alleged questions. First above (hourglasses) was a straight mathematical teaser, but maths has little to do with software. OK, so there is a relationship but these days *any discipline on the planet* is about as related as mathematics, and some are far more relevant. We'll develop this theme in the next post.

Second question above, about pushing cars to a hotel. What's that about? Actually, the real implied question is, "did you grow up with a certain cultural reference?" Again, nothing to do with software (which I think google still does) and bugger all to do with anything else google might get access to. Also rather discriminatory, but that's life.

In closing, I'll conclude: asking or being asked oddball questions is not a correlation with a great place to work. Indeed, chances are, it is reversely correlated, but I'll leave the proof of that for part 2.

DSD launches Cyber Warfare - on my machine...

I'm sitting here minding my own business in early hours of Sunday morning - OK, completing a risks analysis - and my machine starts churning away. Now, if you're an old time guy like me, you'll probably recall when cycles were expensive, kilobytes had deep emotional meaning, and noise delta was trauma. Either way, even though I have the late-gen Mac Air and it has very nice heat management, as well as more sex-appeal than any 10 shares in Facebook, I remain ... sensitive!

Hunting around, I find that the culprit: google's Chrome. Ok, so what page? Well, none and all of them - Google's algorithm seems to have decided to cover my surfin sites with adverts for the DSD - Defence Signals Directorate - which is Australia's spook agency copy of the fabled NSA. Indeed 2 adverts to a page, all in impeccable Flash with zany cool graphics.

Blech. DSD is inviting me - and anyone, seems they're not that fussy - to join their great cyber-warfare jihad against the anonymous planet (us? they ain't saying).

And they've started the campaign by stealing my cycles. No fair!

Not to mention, even Blind Freddy could tell what was wrong with their lame HR campaign. OK, maybe not, but here it is anyway: Firstly, people who are great defenders need great attack skills. Where do these budding ueber-cyber-guerillas get their skills from?

Attacking, is what. Hacking, to use the street parlance.

So we already have an issue - if you've led an exciting life of packet crime, you'll be knocked out in the security process. I know this at first hand - among the hundred-odd interesting factoids of my international life of mystery, the only time alarm bells went off : a mildly amusing moment a few dog-lives ago doing some crypto-manipulation and social-engineering for private pleasure.

Where are we then? Anyone we want working at DSD simply won't be allowed, and anyone who is allowed is suspicious for the same reason!

Which brings us to point 2: the security process. To work at DSD you require TOP SECRET. That's if you're the janitor, and even he's not allowed to know it. And, while it sounds sexy, security clearances are a drag of immense proportions. One year's delay *minimum* (some guy was telling me it took him 13 months to get his TS back again because it lapsed for 12 months ...).

It doesn't take a PhD in Economics to realise this is as dead a duck can be, and that's before we look at public service pay scales.

But wait, there's more! While you're waiting on that coveted TS to come through (and filling in reams of data concerning the mating habits of your first 10 pets) you can't work in the field. They can't offer you a job. They can't even offer you another job.

Bottom line: DSD are conducting a massive poaching campaign against .. themselves. They are advertising for people working in /other government departments/ who already have TS ... so they can steal them. Can you say beggar thy neighbour? DSD can. And when they do manage to steal the hard-won cyber-slave of some poor other schmuck department, they won't pay anywhere near enough to cover the anguish of TS.

Wake up guys!

Save your money! You've been doing this for 2 years now. The pool is fished out. Try another strategy. Sack your PR guy and hire some hackers. And, further, I've shut down Chrome... Cop that!

for bright times for CISOs ... turn on the light!

Along the lines of "The CSO should have an MBA" we have some progress:

City University London will offer a new postgraduate course from September, designed to help information security and risk professionals progress to managerial roles.

The new Masters in Information Security and Risk (MISR) aims to address a gap in the market for IT professionals that can “speak business”. One half of the course is devoted to security strategy, risk management and security architecture, while the other half focuses on putting this into a business-oriented context.

“Talking to people out in the industry, particularly if you go to the financial sector, they say one real problem is they don't have a security person who they can take along to the board meeting without having to act as an interpreter; so we're putting together a programme to address this need,” explained course director Professor Kevin Jones, speaking at the Infosecurity Europe Press Conference in London yesterday.

Why The New Guy Can’t Code

Have you noticed why teams are so much harder to build these days? Here's part of the problem:

We’ve all lived the nightmare. A new developer shows up at work, and you try to be welcoming, but he1 can’t seem to get up to speed; the questions he asks reveal basic ignorance; and his work, when it finally emerges, is so kludgey that it ultimately must be rewritten from scratch by more competent people. And yet his interviewers—and/or the HR department, if your company has been infested by that bureaucratic parasite—swear that they only hire above-average/A-level/top-1% people.

Spot on. Most hiring practices are mostly out of sync with what people actually do. This is endemic; I have yet to see a hiring process that actually lifts above this.

I've no time to write on this now, but I do not understand why companies use such approaches when they have all the evidence in front of them that these practices are a large part of the problem.

profound misunderstandability in your employee's psyche

Speaking of profound misunderstandings, this:

BitDefender created a "test profile" of a nonexistent, 21-year-old woman described as a "fair-haired" and "very, very naïve interlocutor" -- basically a hot rube who was just trying to "figure out how this whole social networking thing worked" by asking a bunch of seemingly innocent, fact-finding questions.

With the avatar created, the fictitious person then sent out 2,000 "friendship requests," relying on the bogus description and made-up interests as the presumptive lure. Of the 2,000 social networks pinged with a "friendship" request, a stunning 1,872 accepted the invitation. And the vast majority (81 percent) of them did it without asking any questions at all. Others asked a question or two, presumably like, "Who are you?" or "How do I know you?" before eventually adding this new "friend."

...

But it gets worse. An astonishing 86 percent of those who accepted the bogus profile's "friendship" request identified themselves as working in the IT industry. Even worse, 31 percent said they worked in some capacity in IT security.

Where does anyone (young) want to go, today?

I got some good criticism on the post about accounting as a profession. Clive said this which I thought I'd share:

As an engineer who's father was an accountant I will give you three guesses as to what he told me not to do when I grew up... Oddly it is the same for engineers, we tend to tell our children to do other things. As I've said before if you want to get on in life you should learn to speak the language that the man who cuts your cheque at the end of the month does, or more correctly his boss ;)

So even if you are just a humble team leader get yourself three courses,

1. MBA,
2. Vocal training,
3. Psychology or Method acting.

And no I'm not joking about 3.

He's talking about what we do when we get to 30 and beyond, e.g., most readers of this blog. For us older folks looking back, it is depressing that the world looks so sucky; but this is a time-honoured thing. The myths have been stripped away, the rot revealed.

But the youth of today is perpetually optimistic, and the question they ask is eternal and (Spence-like) opinionated: what to study, first?

What then do we recommend for a first degree for someone near 20? It seems that nobody promotes the accountancy field, including the incumbents. Accountants don't practice accountancy, if they are any good. The only accountant I ever knew well committed suicide.

An MBA doesn't work, this is something that should be done after around 5-10 years of experience. Hence, I'm not convinced a straight business degree ("Bachelors in Business Studies" ?) makes sense either, because all that additional stuff doesn't add value until experience is there to help it click into place.

I wouldn't suggest economics. It is like law and accounting, in that it helps to provide a very valuable perspective throughout higher business planes. But it doesn't get you jobs, and it is too divorced from practical life, too hard to apply in detail. Engineering seems far too specialised these days, and a lot of it is hard to work in and subject to outsourcing. Science is like engineering but without the focus.

To my mind, the leading contenders as a first degree are (in no particular order):

⇒ law,
⇒ computer science,
⇒ biotech, and
⇒ marketing.

Firstly, they seem to get you jobs; secondly, law, compsci and marketing are easy to apply generally and broadly, and pay dividends throughout life. I'm not quiet sure about Biotech in the "broad" sense, but it is the next big thing, it is the wave to ride in.

Comp sci was the wave of the 1980s and 1990s. Now it is routine. Any technical degree these days tends to include a lot of comp sci, so if there is a tech you enjoy, do that degree and turn it into a comp sci degree on the inside.

Law is in my list because it is the ultimate defensive strategy. Headline Law tends to offend with its aggressively self-serving guild behaviour ("a man who represents himself has a fool for a client and a fool for a lawyer") and as a direct practice (courts) the field seems made for crooks. More technically, all disputes are win-lose by definition, and therefore litigation is destructive by definition, not productive. This is offensive to most of humanity.

But litigation is only the headline, there are other areas. You can apply the practical aspects of law in any job or business, and you can much more easily defend yourself and your business against your future fall, if you have a good understanding of the weapons of mutual destruction (a.k.a. lawsuits). About half of the business failures I've seen have occurred because there was no good legal advisor on the team; this is especially true of financial cryptography which is why I've had to pick up some of it; what one person I know calls "bush lawyering."

The downside to studying law is that you can lose your soul. But actually the mythology in law is not so bad because it is grounded in fundamental rights, so keep those in mind, and don't practice afterwards. It's nowhere near as bad as the computing scene (no grounding at all, e.g., open source) or the marketing blah blah (your mission is to unground other's perceptions!).

Marketing is there because every successful business needs it, and you can only be successful with it. MBAs are full of marketing, which reflects its centrality (and also gives a good option for picking it up later). But marketing is also dangerous because it gives you the tools to fool yourself and all around you, and once you've become accustomed to the elixir, your own grounding is at risk.

I don't advise any of the arts (including Clive's points 2,3) as a primary degree for youth, because businesses hire on substance, so it is important to have some to offer. E.g., people who study psychology tend to end up doing HR ("human resources"), badly, perhaps because they lack the marketing sense to make HR the most important part of the business.

Likewise, avoid anything that is popular, soft, fun, nice and that all your touchy-feely friends want to do. When there are too many people and too little substance, the competition suppresses everyone and makes you all poor. That's the best result because at least it is honest; a very few dishonest ones become rich because they figure out the game. The notion that you can study acting, media, history, photography or any of the finer arts, and then make a living, doesn't bear talking about. It is literally gambling with lives, and has no place in advice to young people.

Where does the accounting profession want to go, today?

So, if they are not doing audits and accounting, where does the accounting profession want to go? Perhaps unwittingly, TOdd provided the answer with that reference to the book Accounting Education: Charting the Course through a Perilous Future by W. Steve Albrecht and Robert J. Sack.

It seems that Messrs Albrecht and Sack, the authors of that book, took the question of the future of Accounting seriously:

Sales experts long ago concluded that "word of mouth" and "personal testimonials" are the best types of advertising. The Taylor Group1 found this to be true when they asked high school and college students what they intended to study in college. Their study found that students were more likely to major in accounting if they knew someone, such as a friend or relative, who was an accountant.

So they tested it by asking a slightly more revealing question of the accounting professionals:

When asked "If you could prepare for your professional career by starting college over again today, which of the following would you be most likely to do?" the responses were as follows:

Type of Degree	% of Educators Who Would	% of Practitioners Who Would
Who Would Earn a bachelor's degree in something other than accounting and then stop	0.0	7.8
Earn a bachelor's degree in accounting, then stop	4.3	6.4
Earn a Master's of Business Administration (M.B.A.) degree	37.7	36.4
Earn a Master's of Accountancy degree	31.5	5.9
Earn a Master's of Information Systems degree	17.9	21.3
Earn a master's degree in something else	5.4	6.4
Earn a Ph.D.	1.6	4.4
Earn a J.D. (law degree)	1.6	11.4

These results are frightening,...

Well indeed! As they say:

It is telling that six times as many practicing accountants would get an M.B.A. as would an M.Acc., over three times as many practitioners would get a Master's of Information Systems degree as would get an M.Acc., and nearly twice as many practitioners would get a law degree instead of an M.Acc. Together, only 12.3 percent (6.4% + 5.9%) of practitioners would get either an undergraduate or graduate degree in accounting.2 This decrease in the perceived value of accounting degrees by practitioners is captured in the following quotes:

We asked a financial executive what advice he would give to a student who wanted to emulate his career. We asked him if he would recommend a M.Acc. degree. He said, "No, I think it had better be broad. Students should be studying other courses and not just taking as many accounting courses as possible. ...

My job right now is no longer putting numbers together. I do more analysis. My finance skills and my M.B.A. come into play a lot more than my CPA skills.

.... we are creating a new course of study that will combine accounting and
information technology into one unique major....

...I want to learn about information systems.

(Of course I'm snipping out the relevant parts for speed, you should read the whole lot.) Now, we could of course be skeptical because we know computing is the big thing, it's the first addition to the old list of Reading, Arithmetic and Writing since the dark ages. Saying that Computing is core is cliche these days. But the above message goes further, it's almost saying that Accountants are better off not doing accounting!

The Accounting profession of course can be relied upon to market their profession. Or can they? Todd was on point when he mentioned the value chain, the image in yesterday's post. Let's look at the wider context of the pretty picture:

Robert Elliott, KPMG partner and current chairman of the AICPA, speaks often about the value that accountants can and should provide. He identifies five stages of the "value chain" of information. The first stage is recording business events. The second stage is summarizing recorded events into usable data. The third stage is manipulating the data to provide useful information. The fourth stage is converting the information to knowledge that is helpful to decision makers. The fifth and final stage is using the knowledge to make value-added decisions. He uses the following diagram to illustrate this value chain:

This five-stage breakdown is a helpful analysis of the information process. However, the frightening part of Mr. Elliott's analysis is his judgment as to what the segments of the value chain are worth in today's world. Because of the impact of technology, he believes that:

• Stage 1 activity is now worth no more than $10 per hour
• Stage 2 activity is now worth no more than $30 per hour
• Stage 3 activity is now worth $100 per hour
• Stage 4 activity is now worth $300 per hour
• Stage 5 activity is now worth $1,000 per hour

In discussing this value chain, Mr. Elliott urges the practice community to focus on upper-end services, and he urges us to prepare our students so they aim toward that goal as well. Historically, accounting education has prepared students to perform stage 1- and stage 2-type work.

Boom! This is compelling evidence. It might not mean that the profession has abandoned accounting completely. But it does mean that whatever they do, they simply don't care about it. Accounting, and its cousin Audits are loss-leaders for the other stuff, and eyes are firmly fixed on other, higher things. We might call the other stuff Consulting, and we might wonder at the correlation: consulting activities have consumed the major audit firms. There are no major audit firms any more, there are major consulting firms, some of which seem to sport a vestigial audit capability.

Robert Elliot's message is, more or less, that the audit's fundamental purpose in life is to urge accountancy firms into higher stages. It therefore matters not what the quality (high?) is, nor what the original purpose is (delivering a report for reliance by the external stakeholder?). We might argue for example whether audit is Stage 2 or Stage 3. But we know that the auditor doesn't express his opinion to the company, directly, and knowledge is the essence of the value chain. By the rules, he maintains independence, his opinion is reserved for outsiders. So audit is limited to Stages 3 and below, by its definition.

Can you see a "stage 4,5 sales opportunity" here?

Or perhaps more on point, can you avoid it?

It is now very clear where the auditors are. They're not "on audit" but somewhere higher. Consulting. MBA territory. Stage 5, please! The question is not where the accounting profession wants to go today, because they already got there, yesterday. The financial crisis thesis is confirmed. Audits are very much part of our problem, even if they are the accounting profession's solution.

What is less clear is where are we, the business world? The clients, the users, the reliers of audit product? And perhaps the question for us really is, what are we going to do about it?

OSS on how to run a business

After a rather disastrous meeting a few days ago, I finally found the time to load up:

The Office of Strategic Services was the USA dirty tricks brigade of WWII, which later became the CIA. Their field manual was declassified and published, and, lo and behold, it includes some mighty fine advice. This manual was noticed to the world by the guy who presented the story of the CIA's "open intel" wiki, he thought it relevant I guess.

Sections 11, 12 are most important to us, the rest concentrating on the physical spectrum of blowing up stuff. Onwards:

(11) General Interference with Organizations and Production (a) Organizations and Conferences (1) Insist on doing everything through "channels." Never permit short-cuts to be taken in order to, expedite decisions. (2) Make "speeches." Talk as frequently as possible and at great length. Illustrate your "points" by long anecdotes and accounts of personal experiences. Never hesitate to make a few appropriate "patriotic" comments. (3) When possible, refer all matters to committees, for "further study and consideration." Attempt to make the committees as large as possible - never less than five. (4) Bring up irrelevant issues as frequently as possible. (5) Haggle over precise wordings of communications, minutes, resolutions. (6) Refer back to matters decided upon at the last meeting and attempt to reopen the question of the advisability of that decision. (7) Advocate "caution." Be "reasonable" and urge your fellow-conferees to be "reasonable" and avoid haste which might result in embarrassments or difficulties later on. (8) Be worried about the propriety of any decision -raise the question of whether such action as is contemplated lies within the jurisdiction of the group or whether it might conflict with the policy of some higher echelon.

Read the full sections 11,12 and for reference, also the entire manual. As some have suggested, it reads like a modern management manual, perhaps proving that people don't change over time!

Robert Garigue and Charlemagne as a model of infosec

Gunnar reports that someone called Robert Garigue died last month. This person I knew not, but his model resonates. Sound bites only from Gunnar's post:

"It's the End of the CISO As We Know It (And I Feel Fine)"...

...First, they miss the opportunity to look at security as a business enabler. Dr. Garigue pointed out that because cars have brakes, we can drive faster. Security as a business enabler should absolutely be the starting point for enterprise information security programs.
...

Secondly, if your security model reflects some CYA abstraction of reality instead of reality itself your security model is flawed. I explored this endemic myopia...

This rhymes with: "what's your business model?" The bit lacking from most orientations is the enabler, why are we here in the first place? It's not to show the most elegant protocol for achieving C-I-A (confidentiality, integrity, authenticity), but to promote the business.

How do we do that? Well, most technologists don't understand the business, let alone can speak the language. And, the business folks can't speak the techno-crypto blah blah either, so the blame is fairly shared. Dr. Garigue points us to Charlemagne as a better model:

King of the Franks and Holy Roman Emperor; conqueror of the Lombards and Saxons (742-814) - reunited much of Europe after the Dark Ages.

He set up other schools, opening them to peasant boys as well as nobles. Charlemagne never stopped studying. He brought an English monk, Alcuin, and other scholars to his court - encouraging the development of a standard script.

He set up money standards to encourage commerce, tried to build a Rhine-Danube canal, and urged better farming methods. He especially worked to spread education and Christianity in every class of people.

He relied on Counts, Margraves and Missi Domini to help him.

Margraves - Guard the frontier districts of the empire. Margraves retained, within their own jurisdictions, the authority of dukes in the feudal arm of the empire.

Missi Domini - Messengers of the King.

In other words, the role of the security person is to enable others to learn, not to do, nor to critique, nor to design. In more specific terms, the goal is to bring the team to a better standard, and a better mix of security and business. Garigue's mandate for IT security?

Knowledge of risky things is of strategic value

How to know today tomorrow’s unknown ?

How to structure information security processes in an organization so as to identify and address the NEXT categories of risks ?

Curious, isn't it! But if we think about how reactive most security thinking is these days, one has to wonder where we would ever get the chance to fight tomorrow's war, today?

Unwinding secrecy -- how to do it?

The next question on unwinding secrecy is how to actually do it. It isn't as trivial as it sounds. Perhaps this is because the concept of "need-to-know" is so well embedded in the systems and managerial DNA that it takes a long time to root it out.

At LISA I was asked how to do this; but I don't have much of an answer. Here's what I have observed:

• Do a little at a time.
• Pick a small area and start re-organising it. Choose an area where there is lots of frustration and lots of people to help. Open it up by doing something like a wiki, and work the information. It will take a lot of work and pushing by yourself, mostly because people won't know what you are doing or why (even if you tell them).
• What is needed is a success. That is, a previously secret area is opened up, and as a result, good work gets done that was otherwise inhibited. People need to see the end-to-end journey in order to appreciate the message. (And, obviously, it should be clear at the end of it that you don't need the secrecy as much as you thought.)
• Whenever some story comes out about a successful opening of secrecy, spread it around. The story probably isn't relevant to your organisation, but it gets people thinking about the concept. E.g., that which I posted recently was done to get people thinking. Another from Chandler.
• Whenever there is a success on openness inside your organisation, help to make this a showcase (here are three). Take the story and spread it around; explain how the openness made it possible.
• When some decision comes up about "and this must be kept secret," discuss it. Challenge it, make it prove itself. Remind people that we are an open organisation and there is benefit in treating all as open as possible.
• Get a top-level decision that "we are open." Make it broad, make it serious, and incorporate the exceptions. "No, we really are open; all of our processes are open except when a specific exception is argued for, and that must be documented and open!" Once this is done, from top-level, you can remind people in any discussion. This might take years to get, so have a copy of a resolution in your back pocket for a moment when suddenly, the board is faced with it, and minded to pass a broad, sweeping decision.
• Use phrases like "security-by-obscurity." Normally, I am not a fan of these as they are very often wrongly used; so-called security-by-obscurity often tans the behinds of supposed open standards models. But it is a useful catchphrase if it causes the listener to challenge the obscure security benefits of secrecy.
• Create an opening protocol. Here's an idea I have seen: when someone comes across a secret document (generally after much discussion ...) that should not have been kept secret, let them engage in the Opening-Up Protocol without any further ado. Instead of grumbling or asking, put the ball in their court. Flip it around, and take the default as to be open:

  "I can't see why document X is secret, it seems wrong. Therefore, in 1 month, I intend to publish it. If there is any real reason, let me know before then."

  This protocol avoids the endless discussions as to why and whether.

Well, that's what I have thought about so far. I am sure there is more.

Unwinding secrecy -- how far?

One of the things that I've gradually come to believe in is that secrecy in anything is more likely to be a danger to you and yours than a help. The reasons for this are many, but include:

• hard to get anything done
• your attacker laughs!
• ideal cover for laziness, a mess or incompetence

There are no good reasons for secrecy, only less bad ones. If we accept that proposition, and start unwinding the secrecy so common in organisations today, there appear to be two questions: how far to open up, and how do we do it?

How far to open up appears to be a personal-organisational issue, and perhaps the easiest thing to do is to look at some examples. I've seen three in recent days which I'd like to share.

First the Intelligence agencies: in the USA, they are now winding back the concept of "need-to-know" and replacing it with "responsibility-to-share".

Implementing Intellipedia Within a "Need to Know" Culture

Sean Dennehy, Chief of Intellipedia Development, Directorate of Intelligence, U.S. Central Intelligence Agency

Sean will share the technical and cultural changes underway at the CIA involving the adoption of wikis, blogs, and social bookmarking tools. In 2005, Dr. Calvin Andrus published The Wiki and The Blog: Toward a Complex Adaptive Intelligence Community. Three years later, a vibrant and rapidly growing community has transformed how the CIA aggregates, communicates, and organizes intelligence information. These tools are being used to improve information sharing across the U.S. intelligence community by moving information out of traditional channels.

The way they are doing this is to run a community-wide suite of social network tools: blogs, wikis, youtube-copies, etc. The access is controlled at the session level by the username/password/TLS and at the person level by sponsoring. That latter means that even contractors can be sponsored in to access the tools, and all sorts of people in the field can contribute directly to the collection of information.

The big problem that this switch has is that not only is intelligence information controlled by "need to know" but also it is controlled in horizontal layers. For same of this discussion, there are three: TOP SECRET / SECRET / UNCLASSIFIED-CONTROLLED. The intel community's solution to this is to have 3 separate networks in parallel, one for each, and to control access to each of these. So in effect, contractors might be easily sponsored into the lowest level, but less likely in the others.

What happens in practice? The best coverage is found in the network that has the largest number of people, which of course is the lowest, UNCLASSIFIED-CONTROLLED network. So, regardless of the intention, most of the good stuff is found in there, and where higher layer stuff adds value, there are little pointers embedded to how to find it.

In a nutshell, the result is that anyone who is "in" can see most everything, and modify everything. Anyone who is "out" cannot. Hence, a spectacular success if the mission was to share; it seems so obvious that one wonders why they didn't do it before.

As it turns out, the second example is quite similar: Google. A couple of chaps from there explained to me around the dinner table that the process is basically this: everyone inside google can talk about any project to any other insider. But, one should not talk about projects to outsiders (presumably there are some exceptions). It seems that SEC (Securities and Exchange Commission in USA) provisions for a public corporation lead to some sensitivity, and rather than try and stop the internal discussion, google chose to make it very simple and draw a boundary at the obvious place.

The third example is CAcert. In order to deal with various issues, the Board chose to take it totally open last year. This means that all the decisions, all the strategies, all the processes should be published and discussable to all. Some things aren't out there, but they should be; if an exception is needed it must be argued and put into policies.

The curious thing is why CAcert did not choose to set a boundary at some point, like google and the intelligence agencies. Unlike google, there is no regulator to say "you must not reveal inside info of financial import." Unlike the CIA, CAcert is not engaging in a war with an enemy where the bad guys might be tipped off to some secret mission.

However, CAcert does have other problems, and it has one problem that tips it in the balance of total disclosure: the presence of valuable and tempting privacy assets. These seem to attract a steady stream of interested parties, and some of these parties are after private gain. I have now counted 4 attempts to do this in my time related to CAcert, and although each had their interesting differences, they each in their own way sought to employ CAcert's natural secrecy to own advantage. From a commercial perspective, this was fairly obvious as the interested parties sought to keep their negotiations confidential, and this allowed them to pursue the sales process and sell the insiders without wiser heads putting a stop to it. To the extent that there are incentives for various agencies to insert different agendas into the inner core, then the CA needs a way to manage that process.

How to defend against that? Well, one way is to let the enemy of your enemy know who we are talking to. Let's take a benign example which happened (sort of): a USB security stick manufacturer might want to ship extra stuff like CAcert's roots on the stick. Does he want the negotiations to be private because other competitors might deal for equal access, or does he want it private because wiser heads will figure out that he is really after CAcert's customer list? CAcert might care more about one than they other, but they are both threats to someone. As the managers aren't smart enough to see every angle, every time, they need help. One defence is many eyeballs and this is something that CAcert does have available to it. Perhaps if sufficient info of the emerging deal is published, then the rest of the community can figure it out. Perhaps, if the enemy's enemy notices what is going on, he can explain the tactic.

A more poignant example might be someone seeking to pervert the systems and get some false certificates issued. In order to deal with those, CAcert's evolving Security Manual says all conflicts of interest have to be declared broadly and in advance, so that we can all mull over them and watch for how these might be a problem. This serves up a dilemma to the secret attacker: either keep private and lie, and risk exposure later on, or tell all upfront and lose the element of surprise.

This method, if adopted, would involve sacrifices. It means that any agency that is looking to impact the systems is encouraged to open up, and this really puts the finger on them: are they trying to help us or themselves? Also, it means that all people in critical roles might have to sacrifice their privacy. This latter sacrifice, if made, is to preserve the privacy of others, and it is the greater for it.

Builders v. Breakers

Gunnar lauds a post on why there are few architects in the security world:

Superb post by Mark on what I think is the biggest problem we have in security. One thing you learn in consulting is that no matter what anyone tells you when you start a project about what problem you are trying to solve, it is always a people problem. The single biggest problem in security is too many breakers not enough builders. Please understand I am not saying that breakers are not useful, we need them, and we need them to continue to get better so we can build more resilient systems. But the industry is about 90% breaking and 10% building and that's plain bad.

It’s still predominantly made up of an army of skilled hackers focused on better ways to break systems apart and find new ways to exploit vulnerabilities than “security architects” who are designing secure components, protocols and ultimately secure systems.

Hear hear! And why is this? One easy answer: breaking something is a solid metric. It's either broken or not, in general. Any journo can understand it.

On the other hand, building it is too difficult a signal. There is no easy number, there is no binary result. It takes a business focus over decades to understand that one architecture delivers more profits for users and corporates alike than another, and by then, the architects have moved on, so even, then the result may not be clear.

Let's take an old example. Back around 1996, a couple of bored uni students cracked Netscape's secure browsing. The first time was by crunching the 40 bit crypto using the idle lab computers, and the second time was by predicting the less-than-random numbers injected into the protocol. These students were lauded in the press for having done something grand.

They then went on to a much harder task, and were almost never heard of again. What was that harder task? Building secure and usable systems. One of them tried to build a secure communications platform, another is trying to build a secure computing platform. So far, they have not succeeded at either task, but these are much harder tasks.

The true heroes back in the mid-1990s were the Netscape engineers who got something going and delivered it to the public, not the kids who scratched the paint off it. The breaches mentioned above were jokes, and bad ones at that, because they distracted attention on what was really being built. Case in point, is that, even today, if we had twice as much 40 bit crypto as we do 128 bit crypto, we'd probably be twice as secure, because the attack of relevance simply isn't the bored uni student, it is the patient phisher.

If you recall names in this story, recall them for what they tried to build, and not for what they broke.

The Founder Paradox

For some reason I keep bumping into the Founder problem. I'm not sure if it is me or the world at large ... but I am currently working with 3 groups, 2.5 of which are afflicted by what management types like to call the Founder Problem, or Paradox.

The archtype in brief goes like this. One person creates an enterprise and gets it off the ground. It is successful and it grows. Pure Brilliance!

But as it grows, it maintains a flat structure with the original founder in the center, and the workers in the periphery. As time goes on, the knowledge accumulates in the founder's head, and the periphery becomes more and more stagnant, and unable to respond to changes and needs.

Generally the enterprise then fails. Usually it is spectacular, always it is painful. Every time, it seems on the cusp of greatness, just before it implodes. Everyone then runs around and blames everyone in sight, bemoaning that it was so promising. "If only..."

Get the picture? Seen it before?

I first saw the archtype when I was doing placement for engineering studies in a small electronics supplier. They made a (then) very advanced opto-electric isolator for the electrical world, and had around 25 employees. I as the pimply skinny arrogant student placement was at the very bottom of that hierarchy.

An instant curiosity for me was that even though the company was organised into 3 or 4 departments (design, production, sales, etc), the founder made all the decisions. And, when I was faced with one of his decisions ... I had to uncomfortably realise that there were people in the world who would routinely make bad decisions. He was one of them.

But how is it possible, I wondered, for this company to be successful, if the very Founder makes bad decisions? Surely corporate success is only built on successful decisions?

The answer is somewhat complex, and has some contributing aspects which have to be listed then passed by: The Founder has stumbled into a niche and exploited it -- so luck, timing and societal channels plays a part. Also, the Founder has succeeded in the areas that were needed in the early days, generally those strictly technical areas. Further, the Founder often succeeded in an area where one thing, one client, one-time, one big payoff catapulted the business to the next level.

Rewards are reaped by those who dare, and who were right to dare. So the company grows.

But as a healthy company grows, the challenges change. More people are doing more work. Entire deals from beginning to end can be made without the Founder participating. Divisions making completely different products can start thinking a different ethos, and be bemused when someone comes along and says "that's not who we are!" This someone is evidently wrong, but how to say that, when they are ignoring the evidence in front of them? (Some of you may recall the medical equipment manufacturer that also made pocket calculators...)

These are all factors, or symptoms. But the real kernel of the problem lies within the human brain.

Our heads are limited within an approximate diameter of 20cm, and no matter how hard we try, all the really high bandwidth channels are locked inside. External channels are many orders of magnitude slower, so for example, even though it took me about 5 seconds to formulate this rant inside my 20cm diameter powerhouse of knowledge, it will take 3 hours to 3 days to write it down through my 1cps fingers ... and you the unlucky reader will still probably need 10^4 seconds to digest it via your 4wps eyeballs ... before you disagree!

I know what I want to say, but I can't get that thought from my head into your head without an awful lot of work. And patience.

Now take this simply problem and magnify it. As the organisation grows, the Founder's head has to cope with rapidly multiplying people, customers, suppliers, laws, press, products, ethics, interests, money, jealousy ... the list goes on and on.

What's different is that in the beginning, the founder said "sod all that, I'll just build it." The bits that the founder knows well are done, and the bits unknown are undone. And, history shows, that was the "right decision" as by definition, we wouldn't be talking about it if flopped. (This is the lucky part -- somewhere there are 10 or so competitors that did flop.)

As time goes on, however, those decisions change from "right" to "wrong." Subtleties like team building, accounting for options, legal filings, channel conflict, 2nd order discrimination, cooperation with competitors, etc grow from the ignorable to the all-consuming.

In essence, the company outgrows the ability of the Founder to manage everything inside one standard-issue 20cm head. Now, this wouldn't be a problem if the system of management then migrated to a different system that could cope with the larger responsibilities. The Founder Problem is that it doesn't; the Founder keeps control and will not migrate.

An essential hubris is then that what worked in the past will work in the future. Something like, "I got us here, so it must be right. I'll get us to the next step."

The future overtakes the past, unfortunately, and what worked in the past won't work in the future. We need more skills, and those skills are hard to come by simply because ... the company doesn't have them. The Founder's skills, especially, have become commoditised by definition, because the company is successful ... at the very task of deploying and commoditising those skills.

Which further exacerbates the situation, as the Founder has commoditised own skills, and is left holding the reins for skills unknown, without knowing it.

That is the Founder Paradox. Solving the Founder Problem requires skills that you don't have, and to get the skills, you need those very same skills to recognise what the Problem is.

Those that have the skills, accidentally, will try and resolve the problems, but the Founder often fails to recognise them as problems. If you lack the experience to understand them as issues, are you likely to agree with costly choices? If those issues are not an issue, in your language, then they don't need resources, right?

This hubris eventually brings the company down. As time goes on, the Founder becomes the blocking force, the stop energy, the person holding the reins as the company races towards the cliff.

In our field, the Founder Paradox is quite common, possibly because spectacular growth is routine. Obviously it is possible to do this ... and win ... as some of those spectacular stories remained spectacular, even after a few decades.

It is however a very rare exception! Bill Gates is the famous exception, in that when he ran his company, he had several hundred people reporting *directly to him*. Decisions were made by him, and senior managers with incredible stock-bonus wealth beyond our very understanding ... would talk of "Bill Time" in hushed tones as their most important asset.

But, and it's a big BUT: Bill Gates is the exception, and being the richest person in the world should give you pause for thought. If you can successfully emulate that process, then you should have a chance of "being the next Bill Gates," right?

You haven't, you can't, and even among the many hundreds of also-rans, there are very very few billionaires who practice that style of management.

Statistically, the average well-trained manager cannot manage more than 10 people directly. Get used to the fact. Worse, the average manager can't go comfortably beyond 3-6 departments. It is no coincidence that the military services, which have to be amongst the best manager-training institutions, construct the smallest unit with around 10 people, and generally replicate upwards in threes.

A more commercial example springs to mind: about a decade back, a youthful programmer built a quick SSL webserver out of an open source SSL implementation, and quickly grabbed a major share of the market; when the company crashed with 80 or so employees, experienced managers from within told me that "he made all the decisions."

Another more normal example than Bill Gates: a financial cryptography firm that worked for 4 long years in the shadow of bankrupcy managed to finally cross into the black and apparently retain its stunning growth of 10 times per year (exponential growth charts posted on the net, even!).

The Founder would say "people keep sending me money!" as his rational for making all the decisions; what he was really saying was "what I chose to do last year was right, so we'll keep doing that, we don't need any new formulas."

Yet, even as they were entering the black, the growth engine was already stalling. Within a year, the growth was dead, and disaster lay at every turn. Another billionaire sacrificed on the alter of his own hubris.

I used to mark the point at around 25 workers, as a sort of metric of honour from my first experience. If you were still making all the decisions, then you were in the way, I'd say, and if you hadn't recognised the problem, you were probably in the way when you passed 5.

That sort of simple metric doesn't work in open source organisations, which is where I am these days, and I don't have an easy metric there, as yet.

Perhaps, you might say, it doesn't work on the net? Sometimes we like to think we can rewrite the rules because of the Internet, open source, sharing, and other blah blah. Unfortunately, while the results of the net are spectacular, the net more reinforces the real rules than rewrites them.

Open source organisations suffer from the Founder Problem as well. A few weeks ago I wrote about how the Linux community managed to avoid the problem; in short the original Founder ceded the control over everything except the kernel. Tellingly, the late Prof. John Lions famously remarked that the original Unix kernel, being 10,000 lines of code, was small enough to fit inside a good programmer's brain. While that line count is no longer true, we do have other countervailing efficiencies these days, and the kernel remains a relatively small element.

That was in response to rumours of governance in the Mozilla project; although Mozilla doesn't exactly have a Founder, it has many similar characteristics: a meritocracy where only one is considered for merit (coding), a belief that developers can solve all problems if they just write more code, and a fairly dominating absence of language and skills in the areas they .. don't have the language and skills. A paradox, indeed.

How then do we solve it? In that lies the paradox. The Founder himself or herself has to solve it. They won't take advice on management, so suggesting it won't help. Employing consultants doesn't help, reading management text books won't help either. Coding won't make it go away, nor tinkering on a new project.

They have to discover on their own that they are the problem, not the solution. They have to figure out how to ease themselves out of the anti-management bind.

I can report, unhappily, but quite comfortably, that there are no easy solutions; I recall working through business school case studies which can only be described as painful. We would figure out early on where the problem lay, and still the case would grind on for several years, the victims working through disaster after disaster, before collapsing.

That all said, our culture rewards every new understanding by criticising the lack of solution. If I can write about it, I must be able to solve it, right? Here's some solutions:

• sell out. Pass the whole problem over to a group that can do it properly. Take the money and retire to become a space tourist, like Thwarte's founder did.
• break up the group into component parts, where each part is freely usable by the other parts. Create a small kernel and then spin off the major portions. This would be the Linux solution, which happens to work because the kernel is more or less free of demands to the users (GPL and all that).
• Pass on to family. Founder problems are always solved eventually, as hubris does not conquer death or old age. Consider the tabloid succession story of the Murdoch empire, for example.
• do what you like doing, and let the managers do the boring bits. I saw this with a management consulting company started by Prof of Business / IT; I forget the name but they were the only successful creator of smart card money, and the managers carefully allowed the founder to write his management text books.
• Founder eases out. A migratory path is chosen that moves each little thing of importance from the Founder's head into another's head.

Even if the founder eases out, there is always a fair chance of collapse. Again, instead of being seen as the original failure of the founder, it reinforces the hubris: "I knew I shouldn't have left, see what they did to my baby?"

Who can prove it wrong? No-one, and in that lies the Paradox. Thoughts?

on Leadership - Plants, weeds, and harnessing Stop Energy in your pet Triffid

Meredith Belbin [1] did some stunning research on teams, and postulated that there are, in good teams, 8 or 9 roles [2]:

Shaper	Plant
Co-ordinator	Monitor Evaluator
Completer-Finisher	Implementor
Team Worker	Specialist
Resource Investigator

We know about Specialists, and our computing world is chock-full of Implementors. We can't have too many coders... Completer-finishers are like distro people, and Shapers are like visionaries. The others are more or less familiar.

It is the Plant I want to discuss today.

PL Plant - Characteristics

Individualistic, serious-minded, unorthodox. Plants are innovators and inventors and can be highly creative. They provide the seeds and ideas from which major developments spring. Usually they prefer to operate by themselves at some distance from the other members of the team, using their imagination and often working in an unorthodox way. They tend to be introverted and react strongly to criticism and praise. Their ideas may often be radical and may lack practical constraint. They are independent, clever and original and may be weak in communicating with other people on a different wave-length.

Sound familiar? What that little summary doesn't say is that the Plant is named after the potplant in the corner of the room, who also rarely says or does anything in the team meetings. But when they speak, they cause commotion - they stop everything.

They might have been better off naming it the Cactus. This dangerous characteristic might be what
Dave Winer calls it StopEnergy, and if so, he's partly right and partly wrong. What is going on here is that some very bright guy who cannot communicate to save his life suddenly stood up and said "*That Won't Work!*" What's more, he's likely very offended at the very notion that it was suggested...

In teams within normal humanity (that is, non-computing), Plants are a rarer form of life, less of a worry, but in computing, this garden grows with bounty. So when Belbin above suggests "Too many Plants in one organisation, however, may be counter-productive as they tend to spend their time reinforcing their own ideas and engaging each other in combat" you can see how the computing garden starts to resemble the Day of the Triffids.

Now, your first impression might be to pump up the DDT can and go on a nature clearing ... but wait! What Belbin suggested -- strongly -- was that the good teams had one of every of the above roles. Including the Plant! Prickly, cactus-like, tripodal, full of StopEnergy, however you like to characterise him, the Plant performs a very valuable role: He stops the group going down a doomed path. Only the Plant has the breadth, the depth, the experience, the technical know-how, the empathy with the very soil of the mission and the arrogance to see in an instant that whatever had grabbed the delicious attention of the rest ... was nonsense.

Sadly, the Plant can't communicate. He has to argue, to cause chaos, to attack, to not budge. Which is why you really hope there is only one in the room, and sometimes you feel like the only answer is destructive.

But after all that, consider the complexity of systems: before it works how many of you know it will? The Plant knows it won't, and frankly, the statistics are on his side. That's because so much of what the rest of us do is to grasp at marketing hype, the buzzwords of the month, the framework of the quarter, and how to re-energise the perpetual energy of the faithful. More faith, we cry! "You're an idiot," the Plant helpfully says...

What we don't do is go back to first principles and work out what works. The Plant does, and he's sometimes brave enough to stand up and go against the flow.

How then to handle the Plant is a task of deep and extreme interest to the leader of computing teams. He cares for the mission, even if he offends with every word. The rest of the group needs to be aware that when a true Plant speaks up, it's time to listen, not be offended. Go the extra distance to water that garden. When the Plant speaks, be aware. Beware.

But the rest of the team also need to create. We also need to move forward! The Plant won't give us the ideas, the team has to build them, only to have them knocked down by the Plant. So engaging the Plant, and keeping him at an appropriate, distanced but familar and inclusive attitude is critical to utilising him. We therefore do not glorify the Plant's role, rather we recognise it and look to help the Plant to develop the social skills to bring his perspective to the table. And look to creating the space within the team to let the Plant send out his early warning signals.

Of course, this all is no easy thing. True plants mingle with true weeds, and to the inexperienced gardener, they are indistinguishable. Belbin suggested that as much as 30% of a team are make-weights, and I wrote earlier about the RTFM factor and how it pervades our world. Unfortunately, it takes far less skill to repeat "RTFM" and pretend to be a Plant than it does to really acquire those deep and broad skills. Frankly, there are far more weeds in our tech garden, and our need as leader is to determine who has a long and productive record of growth, and who just messes up the garden. C.f. Belbin's comment above about multiple Plants. You may now be wondering whether we are talking about StopEnergy or instead, the Loner, as introduced by Mitchell.

As leader it is your job to find out.

Why do I write all this? With such conviction? Of course, because I am a Plant. The Plant, even, when it comes to certain interests of user security. The Belbin tests pegged me as a natural triffid, and led me on to the next step: strengthening the other characteristics. These days, I spend most of my free time on projects where I cannot be the Plant, so I must adopt other roles. (Today, that of a Coordinator. It's a non-techie mission, and we have our full compliment of Plants already. We have our Resource Investigator and Shaper, we sorely lack Implementors, but I'm conflicted in that.)

Which brings us back full circle to my original claim - that leaders adopt the roles that others cannot do, appreciating their team members for the roles that they can and do fill.

Now, I don't claim to be a leader, let alone a good leader. I claim to be knowledgeable in it, and capable of spotting one when I see one. I can step aside when someone better comes along, or I can fill in the gaps, albeit in a 3-legged vegetarian sort of fashion.

The gap I'd like to point out today is that the Plants are a great help. Indeed, Belbin says critical. I won't push the point that all Plants are critical all the time, rather I'll agree with Frank:

I believe that dissidents can play a critical role in ensuring a project’s health in the long term, however annoying they might be in the near term.

You the leader need to water this garden, and you can do so firstly with an understanding of roles, secondly with a good understanding of negotiation, and finally, you also need a sense of avoiding the weeds, who latter might be the StopEnergy mentioned earlier. (For that latter, you need technical knowledge and patience, sorry.)

This task is doubly hard as the Plant will respond in a bad way if you treat him badly, thus confusing the signals. But underneath, he really wants to be your early warning device, and he can be harnessed as such, if you're ready and prepared for him.

---

Notes on Belbin: 1. Unfortunately Belbin is a sold product but there appear to be some Books. On their site you can see various ways to buy the product. Disclosure: I have nothing to do with them, I just went through their process at b-school.
2. It was 8, then it was 9!

on Leadership - how to achieve the impossible with the five phases of _win-win_

Last week's post introduced negotiation as a battle between win-win and win-lose. Win-win sits in contrast with win-lose. The two do not go together. This gives us a few things to consider.

• Which are we in?
• If in win-lose, how do we defend ourselves?
• And, if in win-lose, how do we move across to win-win?
• If in win-win, *how do we do it?*

Today's entry addresses how to do win-win, the last of the above. It's only a start. You will not win by reading today's entry - you will just see a glimmer of the end-point today. Let's get stuck in.

Win-win negotiation is done in phases. There are five of them:

1. Relationship. Getting comfortable with each other, establishing common language.
2. Exchange. Exploring views and exchanging information (but NOT passing judgement or pushing anything).
3. Solutions. Crafting of potential solutions, again without judgement.
4. Selection. Selecting and refining the winning solution.
5. Implementation. Ensuring delivery.

The above might be considered the strategy of win-win. It is the high level framework within which we work.

---

P1. Relationship

"When individuals having no established relationships are brought together to interact in group activities with common goals, they produce a group structure with hierarchical statuses and roles within it." Sherif's Hypothesis, part 1

The essence and mission of relationship is:

to establish our means and methods of communications.

How do you talk to someone you've never met before?

It takes a while for a rapport to be established - to understand how it is that the other side likes to communicate. How this is done is totally open - business lunches, beer, social engagements, mutual acquaintances, or just chit chat over the coffee machine.

There are two main mistakes in developing a relationship. Firstly, rushing things. That is, the speeding up or dropping completely of the phase. Rushing into the negotiation without having established a rapport will result in various errors in protocol, and there will be no basis on which to fall back on when suspicions arise.

Secondly, introducing elements of the negotiation-to-come in the hope of getting an early lead. This won't work in negotiation; it is a win-lose tactic, and will rebound later on.

It takes a fair amount of experience to figure out when to move on to the next phase, but this is akin to normal social skills. Both of you will know when you are comfortable to move on, because your relationship will tell you that.

Relationship may appear to be an odd investment to make, but it is important to keep in mind that win-win is a long term strategy. Any time spent early on in establishing relationship is paid off over many future rounds. If those future rounds aren't expected, this would question the very foundation of the negotiation. But even then, in those future rounds, expect to drop back into Phase 1 on a regular basis.

P2. Exchange of Information

"go hard on the facts, soft on the people." [Old Dutch Expression]

In phase 2, we seek to share information, and only information.

It is an act of faith in win-win negotiation that there is a solution, or at the least we are better off discovering the impossibility of the solution, than going to win-lose. So in order to find that solution, we have to move away from the obvious -- if it was obvious, we wouldn't be here, right? -- and dig deep into the non-obvious.

In order to move forward into the non-obvious, we need real information. Hard facts, scary fears, the needs that the other person wouldn't ordinarily share with us. That's our goal:

to share the facts, needs, and fears necessary to craft solutions.

Now you see why Phase 1 was so important: In order to delicately express "home truths," "secret needs" and "fears," without launching into the verbal warfare, we need a solid relationship. How strong? One strong enough to get us past the Prisoners' Dilemma economics of cheating with the information we are about to share. One strong enough to let us suspend our prejudices and defences for a while, to really step into the other guy's shoes, without fear.

How do we go about this? The first and most necessary lesson is to separate out the information from the people. Facts are are not personal unless you make them so, so we need to avoid the language of "he said, she said," as that leads to personal attacks and defensiveness.

Personal opinion is dangerous. It is almost always outwards, accusatory, indeed that's what we mean by personal opinion as opposed to neutral observation. It takes our fears and ascribes blame for them to the opponent; it assumes the opponents fears and creates a need for defence.

Yet, those fears are real. Underlying those fears are real needs, real facts, and real clashes for which we need real solutions.

In order to find the non-obvious, we need to change our very behaviour. This does not mean avoiding the fears and hiding the needs. Far from it:

• We suppress the individual, and we step aside from opinion.
• We search for the actual facts that we need to deal with.
• We share our fears, and express our interests.
• We acknowledge each other's fears and interests.
• And we avoid conclusions or positions like the plague!

The techniques of win-win negotiation are replete with ways to express these in a neutral and non-accusatory fashion. There is a lot more to this than can be pressed into these few words. In brief example, consider that

"You choose to endanger users by blocking information from them."

Sound familiar? This statement is disastrous. It ties dangers to one person's actions, thus it is threatening. Because of the personal claim, it is accusatory. As it includes a direct accusation of intent to harm, it's also distracting from any reality. In the face of such an attack, defensive barriers will go up and no forward movement is possible.

How then can we express our fears, which really are present in the above, notwithstanding that I thrust the blame for those fears on some poor innocent bystander?

That is the essence of the exchange of information. We need to extract the facts, and present them neutrally.

"Users appear to be suffering from frequent attacks, which is a grave concern of mine. What information does the user have to deal with those attacks? One view has it that the user can't deal with any information, even if they were given it. Another view is that some users can deal with it, and they can help us refine what would work for the rest."

My fears are present. The blocking of information is recast as a question to establish what is present. And, there are different ways of looking at this, so let's get both of them there and see why each is attractive, and what problems exist with both sides.

Remember, this phase is about searching for what we know. Once we get facts out on the table, in a neutral setting, then the solutions will start to emerge by themselves. There is no obvious transition to the next phase, it simply happens as a consequence of the surfacing of the hidden information.

P3. Exploring of Options

As the facts come tumbling out, in general, lots of good ideas will also come out. If there is a solution to be found, it will start to become apparent when enough new information hits the table. When one solution turns up, it will often be quickly be followed by others, or variations.

In the exploration of options, our intent is to develop them, and to compare and contrast them. Our goal is to:

to explore many solutions, as they arise, without prejudice, and without conclusion.

In exploring, our tendency is to rush in and grab the first that comes to mind. This is a mistake -- remember, if it was that obvious and that easy we wouldn't be here! The difficulty of our position is testament to the complexities we face, so let's treat those difficulties seriously and not just grab at the first idea, declare victory and head for the bar.

This is like whiteboarding. Or brainstorming. The difference between those terms and negotiation is that we are placing the techniques in a context to get to there, and onwards, not just announcing that at today's meeting we will whiteboard and nothing else.

In exploring these solutions, we use the full gamut of enthusiasm. Try and draw people in, to express ideas. Let a few arguments run on. Look for the crazy ideas, all that good brainstorming stuff.

We try to craft at least three solutions, as that makes it dynamic (it breaks any deadlock between two solutions, and it encourages any fourth or fifth). Cross fertilisation is good too.

P4. Selection

Once we have started the free and open exchange of information, then slowly the solutions that arise. Once the the solutions start their dance, they will also naturally sort themselves out into various preferences.

Now is the time to recall open exchange. The surfacing of interests early sets the stage for an honest understanding of what benefits who and when. This allows for a fuller resolution of the issues, with shared benefits.

The danger here is that as the prize comes closer, some will realise they can win more than others. There will be a tendency to sink into the mire of politics; you should call these pullbacks by surfacing those as interests. "Yes, Bob does need to deliver a win to his department, but we need to balance that against..."

Recall, there are multiple rounds in the win-win game. Those people who push too hard this time to get their big win will be back in the ring next time, because they want to win again. But then, everyone will recall who made out like bandits and those bandits will suffer, as will the entire group.

P5. Implementation

This is the Follow-up phase. Because there is a next round, it is important to implement the chosen solution fully and make sure that all the parties enjoyed their benefits. That is, when you go into the next round, if the previous round stopped after the talking, there won't be much point in another round.

Only delivered solutions feed into the next round, and those that deliver the solution will earn more respect in the next round.

---

That concludes a shockingly brief discussion of the five phases of win-win negotiation, as well as the overall discipline of negotiating itself. It's not quick. It's not sure. Today's title was a bald-faced lie.

I suggest however that win-win is a whole lot more rewarding than anything else on the table.

I'll leave you with three caveats.

There remain more questions than answers, and while I don't want to take all the fun of learning away, I'll tell you where most of them are answered: You need to learn the many, various and peculiar tactics of negotiation. If you ever get a chance to go on a course or browse the net about negotiating, you will find lots of tactics to assist.

Those techniques all fit within the general rubric of negotiating, within the 2x2 of the prisoners' dilemma, within one of the two sides, or in the interaction. It makes a lot of sense to know where they fit within today's context of five phases, or how they assist in the list at the top. Unfortunately, most writings on the subject are weak, so you will have to apply the framework yourself.

Next. Learning negotiation is almost a lifelong quest. It does involve a change in your behaviour, unless you happen to be one of the people who have the skills already beaten into you (pop quiz -- who are they? yes, they exist). Changing behaviour is very tough, especially for techies.

Finally, be aware that win-win will not work with a win-loser. If someone is doing win-lose on you, trying win-win will simply fail. So it is essential for you to learn how to recognise a win-loser. Once you get a feel for the above five phases, you'll find it easy but very frustrating -- instead of sharing and taking risks, they keep attacking and trying to abuse the situation.

If you find yourself in a community, try to bring everyone along at the same speed. There's no point in trying to teach the "leaders" win-win, if the techies are all resorting to their natural state. At the meta-level, this is truly a cooperative effort.

on Leadership - negotiating the RTFM into the realm of forgotten schoolyard jokes

Yesterday, I claimed that leadership in tech teams is more or less down to one thing -- communication. That is the one huge gaping hole in our skills. Now, there are certainly other holes, and deep students of leadership (have you read the Kotter articles yet?) will point them out. My claim here is that the comms hole is so big in tech teams that if you fill that you'll be a happy little vegemite; if you fill any other hole, you'll be justing sucking on salt.

Bang for buck, it is communication that will give you the biggest return on investment. You can see some efforts over at Mozo where Mitchell posts on 8 sessions with staff seeking some understanding at mission. Why? She is seeking to reduce the surface area of the discussions at hand. To do that, she has to get everyone on board; first with the things that Mozilla must do, and then on the things that Mozilla thinks it should do. Bit by bit.

Communication in tech teams however goes way way beyond corporate mission statements.

In essence we as leaders have to unwind the RTFM factor. A leader has to know how to deal with the deep-seated needs of tech people and how to acquire and transmit the information needed for all the people to contribute. The way to deal with this is a little known skill and science called negotiation.

So let's talk about that. First, definition. What is negotiation?

Negotiation is the reaching of agreement, where before there was none, by means of dialogue and communication.

How often do you negotiate? Much more than you think. In fact, almost all difficult discussion falls under the rubic of negotiation. Negotiation occurs whenever there is an issue of contention. It happens when you buy a house, marry, discipline a child, choose a school, pick a restaraunt, ask your boss for help, as well as buying an orange at a fruit market.

Do you disagree? Then we must negotiate. If we do agree on this point, it was an easy negotiation, and maybe you can save yourself the bother of reading further.

Most people think of negotiation as something that happens rarely, when buying something with an uncertain price tag, or trying to get a raise in your job. That is a mistake; negotiation is the process that occurs whenever there is some form of dispute or disagreement that is resolved by discussion.

Most people don't ever get a chance to learn it properly, and pick it up as they go along. For this reason, most people make terrible negotiators. There are a very few naturals, but for the most part, only learning some home truths will set you on the path to real negotiation. There is only one large group in society that has negotiation beaten into them, and they are *not* represented well in the techie field.

So I will ignore them for now, and thrust on. Let's talk negotiation. Let's negotiate some serious talk.

Negotiation divides into two halves: win-win and win-lose. Win-win sits in contrast with win-lose. The two do not go together, and much of ones basic skill is in knowing when each is appropriate, how to move between the two, and stick with the appropriate one. Today's post is really about win-win -- explaining the much over-hyped and misunderstood term of win-win.

The basic principle behind the separation of negotiation into these two components is known as The Prisoners' Dilemma. In this simple problem, two people have to cooperate, but the problem is such that if one of them cheats, that cheater earns a larger payoff.

Who wins?	I lose	I win
You lose	(failure)	win-lose
You Win	win-lose	win-win

The Prisoner's Dilemma is a game from economics. Do not be scared by this, it is a very simple game, with some wonderful and thought provoking results that explain many complexities in your day to day life. Understanding this game will payoff in many ways -- the first of which is why Frank's suggestion of Reciprocity works!

This problem is a dilemma, because the total payout if we cooperate is higher, but the individual payout if one can successfully cheat is higher for the cheater. Do we cooperate or do we cheat? (These tables will be better on the HTML - click the link). But if we both cheat, we both lose big time.

Payouts: yours / mine	I cheat	I cooperate
You cheat	-10 / -10	10 / -20
You cooperate	-20 / 10	5 / 5

In the above table, see how if only one of us cheats, the payout for the cheater is high, but the cooperator is punished badly! If we both cooperate, we get less each, but we are both in the positive.

Now add the numbers together - the sum for both of us cooperating is 10, and all of the others squares are summed to much less. So, as a group, we are better off cooperating, and individually, we are better off cheating, but making sure the other does not cheat. Are we saying that we need to cheat, but stop the other person cheating?

Sounds like real life, right?

Classically, we talk about two accused crooks brought in for questioning by the police -- they are the two prisoners in the dilemma. If both of them keep quiet, then both walk, as there is no real evidence of the crime. If one of them blabs, then the other goes to jail for a long time because he also lied, while the blabber gets off lightly for turning evidence. The question is, for you as a crook, how do you stop the other guy blabbing?

What can we do to try and reach the best payoff? How can our two crooks stay out of jail? These are the central questions of negotiation - once answered, they allow a selection of tactics and process that helps achieve the best payoff.

Before we can achieve the best payoff, we must know in which square of the Prisoner's Dilemma we find ourselves. Let's imagine we have decided to go for a group benefit -- the common good. How do two crooks ensure that neither blabs?

Several ways! They could work together and establish trust, by doing lots of heists, one after the other. Alternatively, the two crooks could employ revenge - if Joe blabs and Fred goes to jail, Joe will find the mob chasing him later on. This expands the basic game into a more complex form of game involving external payoffs. Another way is to establish trust via bonds. Maybe marry each other's sister, or owe each other a bounty?

The key then is to create an external context and to add something else to the game. In the first suggestion above, the two crooks expect to do many jobs in the future. So, their combined payoff in the future depends on doing many jobs together, and they can only do that if they keep together as a team. In the second suggestion, they add a future punishment, so that the rules of the game, and the consequent payoffs, are modified to ensure the cheater loses his incentive (see Stag hunt). Finally, they create Family - which is an extended, powerful relationship. Just like a company, or a tribe, or a football team, our two crooks can bond together in a group that carries them past today's challenges.

In simple terms, they can change the payoffs. The more complex solution is to make the game a repeating game. That is, to make each dilemma one of many, so that each cheating payoff has to balance the loss of potential future shared benefits.

And, that is the key to understanding whether one is in a win-win scenario or a win-lose scenario:

Is this the only time we negotiate? Is this the end of the game? Is there another round?

If there is more to come, then you are, basically, in a win-win negotiation session. If there is no more to come, then you are in win-lose.

That's the first and most basic lesson of negotiation.

Am I in win-win or win-lose?

You must ask yourself this question so frequently it becomes second nature. And, this question is often the same as asking

Is this the only time we negotiate, or do we have a future?

As much second nature is your assessment as to whether you, or your negotiating partner, is considering the future or not.

From here, the world forks. You go to either the relationship process of win-win or, you go to the best payoff of win-lose.

Which are you in? If it is not obvious, you will find out if I post again.

on Leadership - tech teams and the RTFM factor

Leadership is not measured by titles, or by pay or by department sizes. Nor is it measured by columns of ink in a sunday rag. Quite the reverse, really -- when some journo starts talking about leadership it's generally a proxy for Company's stock price, PR budget and journalists' ignorance or lack of inspiration.

To get to today's point we have to build up a picture of structure - what it means to be part of a team. Let's talk about people that are team members, the vast majority, even though we are writing to leaders today, whatever they are.

Consider Alice, a new, junior and very inexperienced programmer. She attempts to establish territory in an area, her first area of deep knowledge. This is a natural desire as it gets a foot on the ground, from which she can start to contribute.

In a complex engineering field like Internet, we have lots of different territories: systems programmers (where I hale from), applications programmers, graphical programmers, graphical artists, ... etc etc. Generally, a programmer dives into one of these areas and tries to make it their profession - their specialty. But in doing that, they inevitably find that this is at the cost of the other areas.

I for example know lots about systems programming, but nothing about graphical programming. Indeed, it's worse than that, because within systems programming there are dozens of areas (crypto, protocols, device drivers, OS, client-server, database, accounting, languages, real-time, capabilities, ...), and I imagine the same is true of graphical programming, if I ever bothered to ask.

How then does our new programmer thrive and learn in her chosen specialty? Traditionally she does it by herself. Alice learns. Swots, reads, surfs, codes up some stuff, etc etc.

What she doesn't do is ask someone to teach her. Bob, who may be the world's expert in GUI programming, for example may be sitting next to her and have all the knowledge she needs. But, if Alice asks "how do I create a widgit?" she'll be told *RTFM* -- read the f&&king manual. The best Alice can do is talk to Dave who happens to be at her level, and in her specialty. Dave also doesn't know how to create a widgit, but at least they can enjoy their conversation about it.

The reason for this is perverse: in order for Alice to deserve to be given that help from Bob, she has to prove that she is capable of using and appreciating that information. There's no point in passing on that knowledge to someone who isn't capable of using it! But the only way for Alice to show she can acquire that knowledge is to do it -- to acquire the knowlege.

This chicken and egg situation explains why computing people are so apparently antagonistic to each other if they arrive from different levels of knowledge. By asking for something you should be able to get yourself, you are revealling yourself as incapable of figuring it out. In contrast, when you know, and someone asks you some small informational question, you are bound by the arcane unwritten rules of the league of extraordinary programmers to tell that person to RTFM. It's an unfortunate truth, an economic hard reality that self-learning is more effective that teaching in the computing world.

So we have a communication issue up and down the levels. Communication between peers at the same level is good, and I guess it has to be otherwise we'd all die of loneliness. But now couple this situation to the above - the diversity of specialties. (We are getting closer to the point now.)

When I come in with all the knowledge in some specialty (today I should be working on datagram security protocols) and talk to some other expert, Carol, in some other field (say, GUIs for email clients), I have a problem. My brain is steeped, literally soaked in RTFM juice. So when Carol asks how to do a cryptoblahblah operation, my kneejerk reaction is to tell her to RTFM. And, even if I can see that she is in the wrong specialty, and she can't possibly be expected to know this or aquire this information, *and* I manage to quell the quivering knees by tying myself in knots of politeness, I still can't help her by explaining it to her, because ... I don't know how!

As a specialist I've spent my entire life reading, learning, coding, doing great things, but all of this has been done by myself. I've never had to teach anything to anyone, and so I simply don't know how to do it. Carol of course is exactly the same, except she's more colourful at it.

So now we see how complex heterogeneous teams have a real problem that homogeneous teams do not have -- and hence a real need for leadership. The more diverse the people are, the more that they lack a common language.

Imagine it like silos -- language frequently used in the financial world. In an OS project like Linux, the teams are all quite homogoneous. All the people in the kernel team are kernel hackers, pretty much, and the Unix kernel was famously designed to be comprehensible by one talented person (the late great Professor John Lions made the point that 10k lines of code, which was what v6 kernel was, could just about fit in a person's brain).

But over in the heterogeneous world of say Firefox, we likely have lots of silos: graphics, layout, protocol, systems interfaces, plugins, crypto, certs, human languages, computer languages ... and these are all completely distinct specialties. Probably every area alone exceeds John Lions' 10k brain limit.

Now look at a leader's problem. You have a lot of people who know a lot of stuff, are convinced that they know a lot of good stuff, yet they know very little of each other's areas, and what's worse, they lack the ability or skills to communicate. Even if they wanted to, they cannot. A nightmare!

A leader in this field then needs exceptional communication skills, to make up for the lack within the team. She has to bring together two or more experts who are both desperately trying to yell as loud as possible "RTFM!" at each other. Unto the breach, she goes, and like as not, they'll both turn and attack her, because she reveals that she doesn't know enough about *either* speciality.

So, it is no small wonder that these teams are hard, and that there are very few leaders. Who'd want the job? It's the worst of all jobs: you get RTFM'd by all your team members, when they are not RTFMing each other, and because you don't get seen as a specialist, you can't even stand on your turf and defend that. It's lose-lose-lose all the way, and in a world where the star is the loudest, the brightest, the most colourful, you also end up getting the lowest pay.

It's worse than that even, in the open source world, as we haven't even got the facade of professionalism and pay to smooth over the gruesome truth. But we've got to the essential point - leadership in the heterogenous team situation is hugely about communication. Massively. And, we are not talking "good communication skills," we are talking exceptional, gifted skills. These are lion-tamer grade, capable of making hungry carnivores purr with pleasure, quelling riots with a look, redirecting warring armies into cooperative ventures.

So, you ask, how then do we acquire these skills? RTFM! The only problem is, the manual for these skills hasn't been written. I am (ahem) writing it and will no doubt get around to it some day, but as you know, I am congenitally impaired when it comes to explaining these things. I've never had to, you see.

on Leadership - roles around the May Pole

Some blogs over in the Mozilla camp are talking about leadership. The thrust of the debate seems to be that it would be nice if we could add a dash of it into open source communities. Sure would, but other than it being nice if it was Christmas every day, what is this really about?

Part of the problem with leadership resolves around what it means. I'll declare my colours up front - if you said that leadership was simply a journo-term for something we don't understand, I wouldn't be arguing strongly with you. There is massive amounts of confusion about it, and we should start by stating that what we don't know about leadership is ... almost everything. Here's what John Kotter, perhaps the world's leading academic on leadership, says:

People are put into leadership positions and ‘magically’ expected to know how to be a leader. Sometimes certifications, such as an MBA or CA are assumed to infer leadership ability. While there are certainly valid assets to these qualifications, they don’t teach you how to be a leader. You can’t learn that in a classroom. You can only learn that in the trenches, emulating others, trying things, and making mistakes as you go. Unfortunately, many of the role models are autocrats, and there is rarely a regular, formal measurement system for leadership. So leaders are left on their own to create their own self-perceptions of their effectiveness.

Kotter wrote two highly influential articles called What do leaders do? and What do managers do? You should look them up in HBR and read them, for many reasons. Here's an example from FactoryJoe (right before he called me egalitarian?!) on what people do:

Here’s what’s strange about it: throughout the meeting (I can’t be sure but…) I did feel like I was sitting in the role of facilitator — not exactly the leader, but close enough. I mean, that’s a pretty common role to play, right? Most meetings need a leader of sorts, right?

Facilitator, definately, that's a key role. But leader? Of a meeting? No, not quite, a faciliatator is a totally normal and necessary process in a meeting. Here's why:

When groups come together and get into the conquering of some grand plan, many roles emerge. A facilitator is one, but there are others. Some research has it that there are 8 or 9 roles, and curiously the most effective teams are with 4 people, where each person plays 2 roles! That research (Belbin) does not identify leadership per se, but it does identify a role that might be traditionally associated: the Chair. This is the person who rules and overrules, keeps the agenda, etc on track.

However that Chair person is not the leader -- a good leader writes themselves out of the forefront role if they can, and will if there is a better person to play that role. In fact, some other research has indicated that a good leader is the person who doesn't do what the others are good at doing, but instead picks out the roles that are missing. So they may play the facilitator today, but in tomorrow's meeting they may be acting as the architect, whereas yesterday they were pushing the tea trolley.

Which leads us to another observation - there can be many leaders, and leadership is not a monopoly.

There might be a manager responsible for a department, but that doesn't mean that his department can't be full of leaders. And what do these leaders do, when not being boss of a department, or being bossed by a bossy boss? Not lead? Well, of course not -- they lead by shifting to other roles and other capabilities, by identifying what's missing, how to get the solution to what's missing, and trying to juggle the factors to make that happen (where, factors include self). It's a bit like that complicated dance around the May Pole, everything keeps shifting, in a merry dance, but that's because the dancers know that the end result is important, not the position they play.

( So, for example, check out the Mitchell posts. In brief but rude terms - 1. some decision lacks are killing us. 2. here's what we are limited to. 3. here's what we should be doing ... each one successively pushing closer to what those decisions should be based on. Not because Mitchel likes to write, but because there is a lack of foundation in what to do. Or, when Frank says that he believes he can list the things that make leadership work, the interesting thing is not whether he's right or whether I'm wrong in saying it can't be done ... rather it is the fact that it is needed, so someone is doing it! )

Tomorrow, I'll post on communications, if someone reminds me.

Negotiation and the rule of three favours

Over on Guy's blog I noticed his "The Art of Schmoozing" which concludes with these two crossovers to our local work on favour currencies:

#8 Give favors. One of my great pleasures in life is helping other people; I believe there's a big Karmic scoreboard in the sky. God is keeping track of the good that you do, and She is particularly pleased when you give favors without the expectation of return from the recipient. The scoreboard always pays back. You can also guess that I strongly believe in returning favors for people who have helped you.

#9 Ask for the return of favors. Good schmoozers give favors. Good schmoozers also return favors. However, great schmoozers ask for the return of favors. You may find this puzzling: Isn't it better to keep someone indebted to you? The answer is no, and this is because keeping someone indebted to you puts undue pressure on your relationship. Any decent person feels guility and indebted. By asking for, and receiving, a return favor, you clear the decks, relieve the pressure, and set up for a whole new round of give and take. After a few rounds of give and take, you're best friends, and you have mastered the art of schmoozing.

These two points are actually related in game theory. It works like this: negotiation is split into two separate sides (by what is called the prisoner's dilemma, but please save that for another day). These sides are known as win/win and win/lose, and they are like yin and yang.

Most people can figure out what that means just from the titles - when in a win/win we are looking for how we benefit from each other and both come out ahead in the long run. When in win/lose, I try to win at your expense.

Our problem is focussed then on knowing whether we are in win/win or in win/lose. If we are in win/lose, then we definately should walk away from any deal. Schmoozing, in Guy's terms, is pointless in win/lose, because this just gets you deeper into a potential loss. One day, if not today, when you might win.

So how do we determine which we are in? It's not as easy as one would think.

The answer is definately not in words; and in my experience, if someone attempts to impress you with statements like "let's search for the win/win," it's as good a signal that they may be thinking win/lose as win/win. Be careful not to be lulled in by such mere words, as they are stock in trade for the win/loser.

One way to determine is what I think of as the rule of three favours. In this tactic, you offer three unrelated favours to your counter-schmoozer (Guy's #8), and you also put yourself in the position of desiring the return of those favours (see Guy's #9).

But don't desire it too aggresively - the essence here is to see whether the person will accept the favours, and naturally return same when given the opportunity.

Why does this work? It works because win/win and win/lose are very very deep-seated human patterns of behaviour. People are generally either one way or the other. Most people naturally fall into win/lose, probably from childhood battles and the general darwinian environment of the kindergarten. As we grow older and mature some, a lucky few of us discover the higher plain of win/win, and we work hard to develop that attitude.

So if you offer three nice juicy favours to a normal, natural win/lose schoolyard bully, it will be beyond their ability and their understanding to avoid abusing the offering. Which means they will take the favours and not return them. Even if a natural win/loser understands the theory of win/win, he has a choice - either practice win/win at some short term practical and emotional cost, or go with his gut instincts. Either way, he reveals to you whether he is ready for some serious business.

And thus you differentiate your partner. We need to try three times, as one test can be accidental, either way. Two can be a pattern, but three is consensus.

A final tip - don't forget to uncorrelate the favours, so don't mark them all with a pressed flower!

Our Private Bayesian Rules Engine

The Economist has a great article on how psychologists are looking at how computer scientists are using Bayesian prediction engines for things like help wizards and spam filters. The Psychologists asked an unusual question - maybe people use Bayesian logic?

Of course! Er, well, maybe. Science needs to test the hypothesis, and that's what they set out to do:

Dr Griffiths and Dr Tenenbaum conducted their experiment by giving individual nuggets of information to each of the participants in their study (of which they had, in an ironically frequentist way of doing things, a total of 350), and asking them to draw a general conclusion. For example, many of the participants were told the amount of money that a film had supposedly earned since its release, and asked to estimate what its total “gross” would be, even though they were not told for how long it had been on release so far.

Besides the returns on films, the participants were asked about things as diverse as the number of lines in a poem (given how far into the poem a single line is), the time it takes to bake a cake (given how long it has already been in the oven), and the total length of the term that would be served by an American congressman (given how long he has already been in the House of Representatives). All of these things have well-established probability distributions, and all of them, together with three other items on the list—an individual's lifespan given his current age, the run-time of a film, and the amount of time spent on hold in a telephone queuing system—were predicted accurately by the participants from lone pieces of data.

There were only two exceptions, and both proved the general rule, though in different ways. Some 52% of people predicted that a marriage would last forever when told how long it had already lasted. As the authors report, “this accurately reflects the proportion of marriages that end in divorce”, so the participants had clearly got the right idea. But they had got the detail wrong. Even the best marriages do not last forever. Somebody dies. And “forever” is not a mathematically tractable quantity, so Dr Griffiths and Dr Tenenbaum abandoned their analysis of this set of data.

The other exception was a topic unlikely to be familiar to 21st-century Americans—the length of the reign of an Egyptian Pharaoh in the fourth millennium BC. People consistently overestimated this, but in an interesting way. The analysis showed that the prior they were applying was an Erlang distribution, which was the correct type. They just got the parameters wrong, presumably through ignorance of political and medical conditions in fourth-millennium BC Egypt. On congressmen's term-lengths, which also follow an Erlang distribution, they were spot on.

Which leaves me wondering what an Erlang distribution is... Wikipedia doesn't explain it in human terms, but it looks like a Poisson distribution:

Curious footnote - look at who they credited as the source of their graph of distributions.

A new security metric?

I have a sort of draft paper on security metrics - things which I observe are positive in security projects. The idea is that I should be able to identify security projects, on the one hand, and on the other provide some useful tips on how to think past the press release. Another metric just leaped out and bit me from that same interview with Damien Miller:

Why did you increase the default size of new RSA/DSA keys generated by ssh-keygen from 1024 to 2048 bits?

Damien Miller: Firstly, increasing the default size of DSA keys was a mistake (my mistake, corrected in the next release) because unmodified DSA is limited by a 160-bit subgroup and SHA-1 hash, obviating the most of the benefit of using a larger overall key length, and because we don't accept modified DSA variants with this restriction removed. There are some new DSA standards on they way that use larger subgroups and longer hashes, which we could use once they are standardized and included in OpenSSL.

We increased the default RSA keysize because of recommendations by the NESSIE project and others to use RSA keys of at least 1536 bits in length. Because host and user keys generated now will likely be in use for several years we picked a longer and more conservative key length. Also, 2048 is a nice round (binary) number.

Spot it?

Here it is again in bold:

Damien Miller: Firstly, increasing the default size of DSA keys was a mistake (my mistake, corrected in the next release) because [some crypto blah blah]

A mistake! Admitted in public! Without even a sense of embarrassment! If that's not a sign that the security is more important than the perception then I don't know what is...

Still not convinced? When was the last time you ever heard anyone on the (opposing) PKI side admit a mistake?

2 articles on OB - leadership, respect, unstructurelessness

Two good articles on OB ("organisational behaviour") which is a sub-discipline of business studies (a.k.a. the MBA).

First up is Tom Peters saying that leadership is about respect for those you have under your control.

Consider these two compelling quotes from MAJ Gavrilis:

"We behaved as if we were guests in their house. We treated them not as a defeated people, but as allies. Our success became their success."

"We were friendly and respectful whenever we met a Bedouin or farmer, often sharing tea with them in the middle of the open desert. Our behavior sent the clearest message: We cared more about the people of Ar Rutbah than did the Fedayeen. ... After all, we had done everything possible to limit damage to civilian infrastructure and private property. ... We treated enemy wounded and distributed contraband food. I stopped our final assault to institute a day-long cease-fire as a gesture to the people of the city."

Second, an old article by Jo Freeman from the 70's womens movement. Her thesis is that unstructured groups don't exist, and pushing unstructured or free open group concepts must become a facade for the informal but real power structures.

...Thus 'structurelessness' becomes a way of masking power, and within the women's movement it is usually most strongly advocated by those who are the most powerful (whether they are conscious of their power or not). The rules of how decisions are made are known only to a few and awareness of power is curtailed by those who know the rules, as long as the structure of the group is informal. Those who do not know the rules and are not chosen for initiation must remain in confusion, or suffer from paranoid delusions that something is happening of which they are not quite aware.

The HR Malaise in Britain - 25% of CVs are fiction

As discussed here a while back in depth, there is an increasing Human Resources problem in some countries. Here's actual testing of the scope of the issue whereby job employers ask for people to lie to them in the interview, and jobseekers happily oblige:

One CV in four is a work of fiction

By Sarah Womack, Social Affairs Correspondent (Filed: 19/08/2005)

One in four people lies on their CV, says a study that partly blames the "laxity" of employers.

The average jobseeker tells three lies but some employees admitted making up more than half their career history.

A report this month from The Chartered Institute of Personnel and Development highlights the problem. It says nearly a quarter of companies admitted not always taking up candidates' references and a similar percentage routinely failed to check absenteeism records or qualifications.

Example snipped...

The institute said that the fact that a rising number of public sector staff lie about
qualifications or give false references was a problem not just for health services and charities, where staff could be working with vulnerable adults or children, but many public services.

The institute said a quarter of employers surveyed ''had to withdraw at least one job offer. Others discover too late that they have employed a liar who is not competent to do the job."

Research by Mori in 2001 showed that 7.5 million of Britain's 25.3 million workers had misled potential employers. The figure covered all ages and management levels.

The institute puts the cost to employers at £1 billion.

© Copyright of Telegraph Group Limited 2005.

If it found 25% of the workers admitted to making material misrepresentations, that shows it is not an abnormality, rather lying to get a job is normal. Certainly I'd expect similar results in computing and banking (private) sectors, and before you get too smug over the pond, I'd say if anything the problem is worse in the US of A.

There is no point in commenting further than to point to this earlier essay: Lies, Uncertainty and Job Interviews. I wonder if it had any effect?