Financial Cryptography

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?