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:
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?Posted by iang at March 31, 2007 09:11 AM | TrackBack