Archive
Continuous Husbandry
One definition of a system is “a collection of interacting elements designed to fulfill a purpose“. A well known rule of thumb for designing robust and efficient social, technical, and socio-technical systems is:
Keep your system elements Loosely Coupled and Internally Cohesive (LCIC)
The opposite of this golden rule is to design a system that has Tightly Coupled and Internally Fragmented (TCIF) elements. TCIF systems are rigid, inflexible, and tough to troubleshoot when the system malfunctions.
Designing, building, testing, and deploying LCIC systems is not enough to ensure that the system’s purpose will be fulfilled over long periods of time. Because of the relentless increase in entropy dictated by the second law of thermodynamics, continuous husbandry (as my friend W. L. Livingston often says) is required to arrest the growth in entropy. Without husbandry, LCIC systems (like startup companies) morph into TCIF systems (like corpocracies). The transformation can be so slooow that it is undetectable – until it’s too late. In subtle LCIC-to-TCIF transformations, it takes a crisis to shake the system architect(s) into reality. In a sudden jolt of awareness, they realize that their cute and lovable baby has turned into an uncontrollable ogre capable of massive stakeholder destruction. Bummer.
Buffer Gone Awry
Assume that you’re a manager enveloped within the predicament below. On a daily basis, you’re trying to coordinate bug fixes and new feature additions to your product while simultaneously getting hammered by internal and external customers with problem reports and new feature requests.
In order to reduce your workload and increase productivity, your meta-manager decides to add a “buffer” manager to filter and smooth out the customer interface side of your job. As the left side of the figure below shows, the hope is that the team’s increased productivity will offset the doubling of overhead costs associated with adding a second manager to the mix. However, when your customers find out that they now have two managers to voice their problems and needs to, the situation on the right develops: your workload remains the same; you now have an additional interface with the buffer manager (who has less of a workload than you); the overhead cost to the org doubles. Bummer.
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
Keep A Tally
Starting today, keep a tally on the number of times that mangers in your org say the words “schedule” and “quality” over the next month. At the end of the month, compute the ratio of schedule-to-quality pronouncements that you recorded; the SQR. I’ll bet you that at the end of the month, SQR >> 1.
Ya Can’t Put The Cat Back In The Bag
Check out this snippet from “Can Larger Companies Still be Passionate and Quirky?“:
Writing for The New York Times, Adam Bryant conducted an interview with Tony Hsieh, the chief executive of Zappos.com. Part of the interview that intrigued me was Hsieh’s explanation of why he and his roommate sold their company LinkExchange to Microsoft in 1998.
Part of it was the money, he admits. But, mostly, it was because the passion and excitement that permeated the company in the beginning was gone, and he’d grown to dislike its culture:
“When it was starting out, when it was just 5 or 10 of us, it was like your typical dot-com. We were all really excited, working around the clock, sleeping under our desks, had no idea what day of the week it was. But we didn’t know any better and didn’t pay attention to company culture. By the time we got to 100 people, even though we hired people with the right skill sets and experiences, I just dreaded getting out of bed in the morning and was hitting that snooze button over and over again.”
To avoid this happening with Zappos, Hsieh says he formalized the definition of the Zappos culture into 10 core values; core values that they would be willing to hire and fire people based on. Read the interview with Hsieh for details on how they went about this.
With LinkExchange, Tony was wise enough to know that it was fruitless to try and restore the company’s original esprit de corps culture. Once the cat gets out of the bag, it’s pretty much a done deal that you won’t get it back in.
What’s mind boggling to me is that leaders of startups that grow and “mature” over time don’t even have a clue that the vibrant culture of community/comraderie that they originally created has petered out. They get disconnected and buffered from the day to day culture by adding layer upon layer of pyramidal stratification and they delude themselves into thinking the culture has been maintained “for free” over the duration. Those dudes deserve what they get; a transformation from a communal meritocracy into a corpo mediocracy just like the rest of the moo-herd.
Plumbers And Electricians
Putting an expert in one technical domain “in charge” of a big risky project that requires deep expertise in a different technical domain is like putting plumbers in charge of a team of electricians on a massive skyscraper electrical job – or vice versa. Putting a generic PMI or MBA trained STSJ in charge of a complex, mixed-discipline engineering product development project is even worse. When they don’t know anything about WTF they’re managing, how can innocently ignorant project “leaders”:
- Understand what needs to be done
- Know what information artifacts need to be generated along the way for downstream project participants
- Estimate and plan the work with reasonable accuracy
- Correctly interpret ongoing status so that they have an idea where the project is located in terms of cost, schedule, and quality
- Make effective mid-course corrections when things go awry and ambiguity reigns
- See through any bullshit used to camouflage shoddy work or to cut corners,
- Stop small but important problems from falling through the cracks and growing into ominously huge obstacles
- Perform the “verify” part of “trust but verify”.
Well, they can’t – no matter how many impressive and glossy process templates are stored in the standard corpo database to guide them. Thus, these poor dudes spend most of their time spinning out massive, impressive excel spreadsheets and microsoft project schedules so fine grained that they’re obsolete before they’re showcased to the equally clueless suits upstairs. But hey, everything looks good on the surface for a long stretch of time. Uh, until the fit hits the shan.
Maker’s Schedule, Manager’s Schedule
I read this Paul Graham essay quite a while ago; Maker’s Schedule, Manager’s Schedule, and I’ve been wanting to blog about it ever since. Recently, it was referred to me by others at least twice, so the time has come to add my 2 cents.
In his aptly titled essay, Paul says this about a manager’s schedule:
The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.
Regarding the maker’s schedule, he writes:
But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started. When you’re operating on the maker’s schedule, meetings are a disaster.
When managers graduate from being a maker and morph into bozos (of which there are legions), they develop severe cases of ADHD and (incredibly,) they “forget” the implications of the maker-manager schedule difference. For these self-important dudes, it’s status and reporting meetings galore so that they can “stay on top” of things and lead their teams to victory. While telling their people that they need to become more efficient and productive to stay competitive, they shite in their own beds by constantly interrupting the makers to monitor status and determine schedule compliance. The sad thing is that when the unreasonable schedules they pull out of their asses inevitably slip, the only technique they know how to employ to get back on track is the ratcheting up of pressure to “meet schedule”. They’re bozos, so how can anyone expect anything different – like asking how they could personally help out or what obstacles they can help the makers overcome. Bummer.
Byzantine Labyrinth
During the birth and growth of dysfunctional CCHs, here is what happens:
- silos form and harden,
- a bewildering array of narrow specialist roles get continuously defined,
- layers of self-important and entitled RAPPERS emerge, and
- a byzantine labyrinth of processes and procedures are created by those in charge.
This not only happens under the “watchful eyes” of the head shed, but incredibly, those inside the shed-of-privilege are the chief proponents and instigators of all the added crap that slows down and frustrates the DICforce. Peter Drucker nailed it when he opined:
Ninety percent of what we call ‘management’ consists of making it difficult for people to get things done – Peter Drucker
On the other hand, T.S. Eliot also pegged it with:
“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
Scalability: The Next Buzzword
Since I’m currently in the process of trying to help a team re-design an existing software-intensive system to be more scalable, the title of this book caught my eye:
It’s just my opinion (and you know what “they” say about opinions) but stay away from this stinker. All the authors want to do is to jump on the latest buzzword of “scalability” and make tons of money without helping anybody but themselves.
Check this self-serving advertisement out:
“The Art of Scalability addresses these issues by arming executives, engineering managers, engineers, and architects with models and approaches to scale their technology architectures, fix their processes, and structure their organizations to keep “scaling” problems from affecting their business and to fix these problems rapidly should they occur.”
Notice how they try to cover the entire hierarchical corpo gamut from bozo managers at the peak of the pyramid down to the dweebs in the cellar to maximize the return on their investment. Blech and hawk-tooey.
BTW, I actually did waste my time by reading the first BS chapter. The rest of the book my be a Godsend, but I’m not about to invest my time trying to figure out if it is.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 