Archive
No Spin From Greenspun
Jessica Livingston interviews a boatload of founders (32 to be exact) of startup companies in her book “Founders At Work“. The most fascinating interview that I’ve read to date is with Phil Greenspun. It’s especially fascinating because it strongly reinforces “my belief system” that most corpo SCOLs are incompetent and most venture capitalists are obsessed with greed. You know how it is, relentlessly seeking out and amassing stories and evidence that irrefutably “prove” that you’re right while ignoring any and all disconfirming evidence to the contrary.
After reading the Livingston-Greenspun dialog, I was so giddy with ego-inflating joy that I wanted to copy and paste the entire interview into this post. However, I thought that would be too extravagant and probably a copyright law violation to boot. Here are some jucilicious fragments that prove beyond a shadow of a doubt that I’m absolutely right and anyone who disagrees with me is absolutely wrong. Hah Hah! Nyuk, nyuk, nyuk!
We talked to a headhunting firm, and the guy was candid with me and said, “Look, we can’t recruit a COO for you because anybody who is capable of doing that job for a company at your level would demand to be the CEO.” And I thought, “That’s kind of crazy. How could they be the CEO? They don’t know the business or the customers. How could we just plunk them down?” In retrospect, that was pretty good thinking; look at Microsoft: it took them 20 years to hand off from Bill Gates to Steve Ballmer. He needed 20 years of training to take that job. Jack Welch was at GE for 20 years before he became CEO. Sometimes it does work, but I think for these fragile little companies, just putting a generic manager at the top is oftentimes disastrous.
The guys on my Board had been employees all of their lives. You can’t turn an employee into a businessman. The employee only cares about making his boss happy. The customer might be unhappy and the shareholders are taking a beating, but if the boss is happy, the employee gets a raise.
Some of my cofounders and more experienced folks were also stretched pretty thin because of the growth. I thought, “We just need the insta-manager solution.” Which, in retrospect, is ridiculous. How could someone who didn’t know anything about the company, the customers, and the software be the CEO?
A lot of the traditional skills of a manager were kind of irrelevant when you only have two or three-person teams building something. So it was almost more like you were better off hiring a process control person or factory quality expert instead of a big executive type.
The CEO was a guy who had never been a CEO of any organization before, and he brought in his friend to be CFO. His buddy didn’t have an accounting degree and he was really bad with numbers. He couldn’t think with numbers, he couldn’t do a spreadsheet model accurately. That generated a lot of acrimony at the board meetings. I would say, “Things are going badly.” And he’d say, “Look at this beautiful spreadsheet. Look at these numbers; it’s going great.” In 5 minutes I had found ten fundamental errors in the assumptions of this spreadsheet, so I didn’t think it would be wise to use it to make business decisions. But they couldn’t see it. None of the other people on the board were engineers, so they thought, “Well, he’s the CFO, so let’s rely on his numbers.” Having inaccurate numbers kept people from making good decisions. They just thought I was a nasty and unpleasant person, criticizing this guy’s numbers, because they couldn’t see the errors. From an MIT School of Engineering standpoint, they were all innumerate.
Meanwhile, because these people didn’t know anything about the business, they were continuing to lose a lot of money. They hired a vice president of marketing who would come in at 10 a.m., leave at 3 p.m. to play basketball, and had no ideas. He wanted to change the company’s name. This was a product that was in use in 10,000 sites worldwide—so at least 10,000 programmers knew it as the ArsDigita Community System. There were thousands and thousands of people who had come to our face-to-face seminars. There were probably 100,000 people worldwide who knew of us, because it was all free. And he said, “We should change the company name because, when we hire these sales-people and they’re cold-calling customers, it will be hard for the customer to write down the name; they’ll have to spell it out.” And they did hire these professional salespeople to go around and harass potential customers, but they never really sold anything.
Watching Closely
Please tell me what type of manager broadcasts statements like this one:
“Since there were no major accomplishments reported on this task last week, I’ll be watching this task closely.”
When I see or hear comic statements like this, I privately think to myself (but never publicly speak, of course):
- What are you gonna do to help if reported status is not up to your lofty but unarticulated expectations next week?
- Are you gonna issue more pointed and specific threats to the DICs assigned to the task?
- Are you gonna ratchet up the pressure even more so?
- Are you gonna roll up your sleeves, dive in and find out what is halting progress so you can directly or indirectly help?
What would you ask yourself?
Unconscious, Conscious, Bozo, Helper
The following sparsely “bent” UML class diagram (see the end of this post for a quick and dorky tutorial for interpreting the diagram) exposes Bulldozer00’s internal hierarchy of manager types. Yours may be different, especially if you’re a manager.
The Base Class
The hierarchy’s Manager base class supplies all the mundane operations that sub-classed managers inherit and perform. For example, all managers in this particular inheritance tree make project plans, track project progress, and monitor progress against the plans. The frequency at which these behaviors are performed, along with the exact details of how they’re executed, is both manager-specific and project-specific. For example, during performance of the “takeStatus” operation, one manager may require project members to write out detailed weekly status reports whilst another may just require informal verbal status.
The Sub-Classes
The second level in Bulldozer00’s morbid and disturbing manager class hierarchy is more interesting. There are two polar opposite sub-types; Bozo and Helper. In addition to inheriting the boring, mechanical, and necessary responsibilities of the Manager base class, these subclasses provide radically different sets of behaviors. For instance, the Bozo subclass provides an “ignoreDICs” behavior whilst the Helper subclass provides “listenToPeople” and “solicitIdeas” behaviors. Comparing the behavior sets between the two subclasses and then against your own manager(s), how would you classify your manager(s)?
As the diagram shows, there are two Bozo Manager subtypes: Conscious and Unconscious. There’s no equivalent subdivision for the Helper Manager type because all Helper Manager “instantiations” are fully conscious. Hell, since all the behaviors that Helper Managers exhibit are so extraordinarily rare, productive, and against-the-grain, there is no way they can be unconscious and not know what they’re doing.
In Bulldozer00’s experience, most Bozo Managers are of the Unconscious ilk. They continuously execute the counterproductive behaviors forwarded on to them via their Bozo inheritance, but they don’t realize how detrimental their actions and words are to the orgs they’re responsible for growing and developing. Since virtually all their fellow clique members behave the same way, they’re oblivious to alternatives and they can’t connect poor org performance to their own dysfunctional behaviors.
Forgive them, for they know not what they do. – Jesus
Lastly, we come to the Conscious Bozo Manager class. Beware of these dudes, of which there are few (thank god), because they are hell on wheels. These guys/gals know fully well that their behaviors/actions are both locally and globally destructive. But why, you ask, would they behave this way? Well, because they’re out to inflate their heads and wallets and there are no boundaries they wouldn’t cross to achieve their goals.
Advice
If you choose to embrace, internalize, and use Bulldozer00’s class hierarchy to evaluate and “privately” judge your managers, you might want to take these suggestions into consideration:
- Run like hell from the Conscious Bozo types.
- Do your best to bring consciousness to the legions of well meaning, but sleepwalking, Unconscious Bozo types
- Attach yourself like a lamprey to the Helper type
But why the hell would you want to “buy into” Bulldozer00’s manager taxonomy? Great freakin’ question!
Appendix: Mini Class Diagram Graphic Tutorial
Play ISTY For Me
In my experience, the more raw technical knowledge an engineer acquires, the more the tendency for him/her to drift unconsciously into ego-centricity and arrogance. The more specialized the knowledge, the more the arrogance. Having personally overcome this malady to at least some extent, I’m facing a conundrum with a brilliant younger colleague. The conundrum is how to teach the youngster to internalize a sense of humility while trying to remain somewhat humble myself.
Like many academically smart kids with a few years of programming experience under his belt, this kid knows a lot of details about a few topics in software engineering (if it can be called engineering) along with a few details about a bunch of others – especially more abstract subjects like large scale design and architecture. On the topics he has little knowledge of (but just enough to be dangerous), he makes sweeping generalizations that I know aren’t correct based on my long but undistinguished career. However, when I try to gently poke holes in his sweeping generalizations and assertions, he digs in. I then lose my patience and tend to get sucked into the awful, I’m-Smarter-Than-You (ISTY) game. The irony of the situation is that my young friend doesn’t lose patience and he stays “cooler” than I do while playing ISTY. D’oh! Because of this ability to remain cool, ignorant, and overconfident, he no doubt has the makings of a future bozo-type manager. Alas, I hope he doesn’t choose that path because he is truly a remarkable technical contributor who creates value.
Oh well, life would be boring without challenges (<- that’s bozo-management-speak for “problems”) to overcome.
Appliablity
In the “good ole’ days”, products, along with the development and production processes to create them, were much simpler. Modern day knowledge-intensive products require both deep and broad know-what and know-how to be successful in the marketplace. Accordingly, in the “good ole’ days” many front line and second tier managers were skilled enough to man the production lines when workers went on strike. In knowledge-intensive industries like software development, that’s no longer true – even if the manager was an engineer just prior to promotion. It’s especially true in today’s fast moving environment where skills become obsolete as soon as they’re mastered. D’oh!
Another way of expressing the idea above is in the corpo lingo of “appliability”. For the most part, managers don’t have the skills to be appliable anymore. They’re a pure overhead expense to the orgs they work for. Thus, unless they’re PHORs, they’re a drain on profits. The next time a non-PHOR manager tells you that “you’re expensive to employ” retort back “at least I’m appliable” – if you dare.
Dude, Read It The Freakin’ First Time
Recently, I was asked by Joe Manager to estimate the amount of resources (people and time) that I thought would be consumed in the development of a large, computationally-intensive, software-centric system. I dutifully did what was asked of me and posted a coarse, first cut estimate on the company wiki for all to scrutinize. I also provided a link to the page to Joe Manager. Unsurprisingly (to me at least) , at the next “planning” meeting I was asked again by Joe, on-the-spot and in real-time, what it would take to do the job if I were to lead the project. Since my pre-meeting intuition told me to bring a hard copy of my estimate to the meeting, I presented it to Mr. Manager and gently reminded him that I had forwarded it to him earlier when he asked for it the (freakin’) first time.
Apparently, besides being forgetful, poor Joe wasn’t told of the not-so-secret policy that I’m not allowed to lead anyone, let alone a team on a large and costly software development project that could be pretty important to the company’s future. Plus, since Joe’s last name is “Manager”, isn’t he supposed to at least consider planning and leading the effort his own freakin’ self? Or is he just envisioning someone else struggling to get it done while he periodically samples status, rides the schedule, and watches from the grassy knoll.
In a bacon and eggs breakfast, the chicken is involved, but the pig is committed – Ken Schwaber
(Dys)functional Managers
IMHO, “functional” engineering managers (e.g. software, hardware, systems, test, etc) should be charged with: developing their people, removing obstacles to their progress, ensuring that tools and training are available, and streamlining bloated processes so that their people can work more efficiently and produce higher quality work outputs. Abdicating these responsibilities makes these dudes (dys)functional bozo managers in my (and maybe only my) eyes.
It really blows my mind when (dys)functional managers are allowed to anoint themselves “chief architect” over and above individual product team functional leads. It’s doubly annoying and counterproductive to an org when these BMs don’t work hands-on with any of the org’s products day-to-day, and they haven’t done any technical design work in this millenium. If I was their next level manager (and not a BM myself so that I could actually see the problem), I’d, as textbook clone managers love to say, “aggressively address” the BM problem by making it crystal clear what their real job is. I’d follow up by periodically polling the BM’s people directly to evaluate how well the BM is performing. Of course, I’m not fit to lead anyone, so you should totally ignore what I say :^)
Motivility
In one of the Vital Smarts crew’s books (I forget which one, and I’m too lazy-ass to look it up) they mention motivation and ability as two important metrics that leaders can leverage to help people improve performance. To make things simple, but hopefully not simplistic, I’ve constructed a “Leader’s Action Table” (LAT) below using a binary “Present” or “Absent” value for each of the motivility attributes.
Since, by definition, a leader is pro-active and he/she cares about people and performance (both), he/she will take the time and effort to get to know his/her people well. The leader can then use the simple, two attribute , four action LAT to help his/her people grow and develop.
With bozo managers, the story is much different. Even if they stopped thinking about themselves and their careers long enough to consider the individual needs of their people in terms of the two motivility attributes, those bozeltines would get it back-asswards and hose everything up – of course. Instead of a LAT, they’d wield the BAT shown below. BATter up!
Do you think the LAT could be useful? What would your LAT look like? Are there any important attributes that you think are missing from the table? Should one or either of the motivility attributes be multi-valued instead of binary? Meh?
“Half of the harm that is done in this world is due to people who want to feel important. They do not mean to do harm… They are absorbed in the endless struggle to think well of themselves.” – T. S. Eliot
Problems And Challenges
It’s easy to view a situation that requires action as a “challenge” instead of a “problem” if you don’t personally have to effect the change yourself. That’s why managers talk about challenges and workers talk about problems. Since hierarchical command and control corpocracies are inherently stratified caste systems, managers and workers don’t have a chance of seeing the same thing – a prallenge.
The Wall
The figure below shows the financial performance of a successful hypothetical company. During the startup phase, both revenue and profit increased at a linear pace, and then something interesting happened. As revenue rose, profit growth hit a wall and leveled off. Dooh!
So, what happened? In business lingo, the costs to execute the business rose faster than the costs to acquire the revenue. Since we are not company insiders, we can only speculate as to the underlying cause(s) of the performance slip, but here are two out of a bazillion possibilities:
- More bureaucrats were added at a faster rate than people with the skills and ability to execute.
- The company’s execution processes were unscaleable.
Let’s explore these two performance busters.
More bureaucrats were added at a faster rate than people with the skills and ability to execute.
With revenue pouring in, it’s easy to become sloppy and careless with all that dough. Egotistical managers, unconsciously trying to outdo one another by building personal empires, convince their disconnected and aloof next-level managers that they need more people for business execution, regardless of whether they actually do need them. These new additions are often specialists who are only capable of executing narrow slivers of the business. Thus, they spend most of their time in idle mode; consuming more from the company than they contribute.
On the other hand, the new additions may be ambitious, unskilled fellow managers who are tasked with doing what their bosses couldn’t – increase execution performance with the people that they currently have. By adding more sub-managers, each super-manager builds his/her empire and further buffers him/herself from where the rubber hits the road in the execution trenches.
The company’s execution processes were unscaleable.
Unless the company produces widgets or some other simple product that doesn’t require knowledge synthesis and frequent human situational decision-making skills, its business execution processes may be unscaleable. In a sincere but misguided attempt to control and increase execution performance, the company’s managers actually decrease scaleability and they inhibit performance gains by piling more constraining rules and procedures on top of the people who create, manufacture, test, and sustain the product portfolio. Rather than rolling up their sleeves and jumping in with their people to help them get the job done, these managers spend all of their time running around taking status and ensuring that all the rules and procedures are followed.
Can you think of any other reasons why this successful company may have stumbled?
All in all you’re just another brick in the wall. – Pink Floyd
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 