The figure below shows two types of performance evaluation systems; one that measures individual performance and the other which measures team performance.
Even though the figure implies a causal connection between type of measurement system and quality of team output, as usual, I have no idea if a causal relationship exists. I suspect they are statistically correlated though, and the correlation is indeed as shown. I think the system on the left encourages intra-team competition whereas the system on the right catalyzes intra-team cooperation. What do you think?
I really love this elegantly written paragraph by Stewart Brand:
The combination of fast and slow components makes the system resilient, along with the way the differently paced parts affect each other. Fast learns, slow remembers. Fast proposes, slow disposes. Fast is discontinuous, slow is continuous. Fast and small instructs slow and big by accrued innovation and occasional revolution. Slow and big controls small and fast by constraint and constancy. Fast gets all our attention, slow has all the power. All durable dynamic systems have this sort of structure; it is what makes them adaptable and robust. - Clock Of The Long Now – Stewart Brand
If you think about organizations, the people at the bottom of the hierarchy should be the fast components that instruct and inform the slow controlling components at the top, no? However, if those at the top allow, or turn a blind eye to bureaucratic processes and procedures that impede quickness at the bottom, they’re screwing up big time, no? Requiring the builders dwelling in the cellar to jump through multiple, multi-layer review/approval cycles to purchase a 5 dollar part, or go to a conference, or get a custom, but simple, cable built, or add some useful code to a widely used library, can be considered an impediment, no?
Ninety percent of what we call ‘management’ consists of making it difficult for people to get get things done – Peter Drucker
If those at the top of a borg solely concern themselves with “the numbers“, bonuses for themselves, and rubbing elbows with other fellow biggies while the borg’s so-called support groups and middle managers stifle the builders with ever more red tape, then fuggedaboud having any fast components in the house. And if Mr. Brand is right in that resilient, durable, adaptable, learning systems require a mix of fast and slow components, then those at the top deserve the results they get from the unresilient, undurable, unadaptable, and unlearning borg they preside over.
Amazon just sent me a recommendation for this book on the management of complexity:
Since four out of five reviewers gave it 5 stars, I scrolled down to peruse the reviews. As soon as I read the following JAMB review, I knew exactly what the reviewer was talking about. I can’t even begin to count how many boring, disappointing management books I’ve read over the years that fit the description. What I do know is that I don’t want to spend any more money or time on gobbledygook like this.
I get e-mails like this all the time:
In four fun-filled days, and for a measly $2000, you too can become a full fledged, CERTIFIED Scrum Master AND Scrum Product Owner. That’s all it takes to catapult you to the top of the software development world. W00t!
Why spend weeks or months struggling to learn a new language, API, framework, technology, or tool when you can nail this trifecta: leapfrog over your programmer peers, break into the highly coveted guild of management, and prefix a big fat “C” to your title? Quick, quick, jump on the bandwagon before it’s too late. Don’t get left behind!
“A person is smart, people are stupid.” – Agent K (Men in Black)
I’m forever fascinated by how large groups of bright and well-meaning individuals often behave so dysfunctionally as a “whole“. How can that be? It’s because the individual “parts” of an organization don’t determine the behavior of the whole. It’s the part-to-part interactions enabled by, and (more importantly) disabled by, the structure of an organization that determines system behavior. By default, hierarchically structured orgs suppress collaborative communications in the horizontal dimension while catalyzing top down command and control communications in the vertical dimension.
In the vertical dimension, the fact that bosses get to unconditionally decide on how to divvy out tasks and rewards to their “subordinates” below ensures that the dweebs in the lower tiers will do whatever the boss wants them to do with little, if any, frictional blowback. In the horizontal dimension, crucial information can be withheld and collaborative communication suppressed because of peer-to-peer competition for the limited number of coveted slots available upstairs in the ever narrowing pyramid.
When it comes down to it, the primary function of management is to allocate finite org resources to efforts that will subsequently increase revenues and/or decrease costs. By resources, I mean people and money (for salaries, materials, tools, training, etc) and time.
Since projects vary wildly in complexity/importance/size, required skill-sets, and they (should) have end points, correctly allocating resources to, and amongst, projects is a huge challenge. Both over and under allocation of resources can threaten the financial viability of the org and, thus, everyone within it. Under-allocation can lead to a stagnant product/service portfolio and over-allocation can lead to an expensive product/service portfolio. Note that either under or over allocation can produce individual project failures.
To correctly allocate resources to projects, especially the “human resources“, some things must be semi-known about them. Besides desired outcomes and required execution skills, project parameters like size and/or complexity should be estimated to some level of granularity. That’s why, for the most part, I think the #noestimates and #noprojects people are full of bullocks. Like agile coaches, they mean well and their Utopian ideas sound enticing. Thanks, but no thanks.
In an ongoing agile endeavor, the practice for eliciting and applying freshly learned knowledge going forward is the periodic “retrospective” (aka periodic post-mortem to the “traditional” old fogeys). Theoretically, retrospectives are temporary way points where individuals: stop, step back, cerebrally inspect what they’ve accomplished and how they’ve accomplished it, share their learning experiences, suggest new process/product improvements, and evaluate previously implemented improvements.
As the figure below depicts, the fraction of newly acquired knowledge applied going forward is a function of group culture. In macho, command and control hierarchies like culture B, the application of lessons learned is suppressed relative to more flexible cultures like A due to the hierarchical importance of opinions.
Regardless of culture type, during schedule-challenged projects with a fixed, do-or-don’t-get-paid deadline (yes, those projects do indeed still exist), this may happen:
When the elites upstairs magically determine that a panic point has appeared (sometimes seemingly out of nowhere): retrospectives get jettisoned, the daily standup morphs into the daily inquisition, corner-cutting “practices” become best practices, and the application of newly acquired knowledge stops cold. Humans being humans, learning still naturally occurs and new knowledge is accrued. However, it is not likely the type of knowledge that will help on future projects.
Regardless of whether a project is managed as an agile or traditional endeavor, it is well known that the execution team learns and acquires new knowledge as the project lurches forward. It is also well known that individual team members learn and formulate opinions that may be at odds with each other.
In spite of the “we’re all (equal)” scrum mantra, some individual opinions will always be “more important” than others in a hierarchy… because that’s what a social hierarchy does (POSIWID). The taller the hierarchy, the larger the gap of importance between opinions. And the larger the gap of importance between opinions, the lesser the chance that a diverse subset of newly acquired knowledge will be applied to future project activities.
The figure below shows two concepts of “Importance Of Opinion“. On the left, we have the Scrum ideal – we’re all one and all opinions carry the same weight. On the right, we have the reality. The opinions within the pyramid of elite titles strongly influence/skew/suppress the PO’s opinions, the PO does the same to the SM, and the SM does the same to the group of DEVs. Even within the so-called flat structure of the DEVs, all opinions are not created equal.
If ur customer *requires* formal waterfall events like “Sys Reqs Review”, “Prelim Design Review”, “Critical Design Review”, gotta do them.
— Tony DaSilva (@Bulldozer0) March 30, 2014
The customers of all the big government-financed sensor system programs I’ve ever worked on have required the aforementioned, waterfall, dog-and-pony shows as part of their well-entrenched acquisition process. Even prior to commencing a waterfall death march, as part of the pre-win bidding process, customers also (still) require contractors to provide detailed schedule and cost commitments in their proposal submissions – right down to the CSCI level of granularity.
If you think it’s tough to get your internal executive customers to wholeheartedly embrace an “agile adoption” or “no estimates” initiative, try to wrap your mind around the cosmic difficulty of doing the same to a large, fragmented, distributed authority, external acquisition machine whose cogs are fine-tuned to: cover their ass, defend their turf, and doggedly fight to keep the extant process that justifies their worth in place. Good luck with that.
Over the years, I don’t know how many times I’ve heard smug, self-important consultants and coaches spout things like: “If your org doesn’t do what I say and/or you don’t get what you want, you should just leave“. Of course, like much of what they say is, it is literally true – you can indeed leave. However, here’s an interesting counterpoint:
“To say people have choice when they are in no position to make one is disingenuous.” – John Seddon
Consultants and coaches love to spout platitudes and self-evident truths couched in the fancy “new” language of the latest fad. Amazingly, stating the ridiculously obvious is what they get paid the big bux to do. To these high-horse riders, life for others is always much simpler than it really is. As outsiders looking in, they have what Nassim Taleb calls: “no skin in the game“. The only thing they have to concern themselves about is sucking up enough to the executives who run the show so that they can get hired back after their $2k/day gig is done. And saying the right things, no matter how impractical they are to implement, is the way they do it.