It seems that several coaches/gurus/consultants/experts use the term “the team” frequently in discussing their work. AS IF there was one, and only one, team: “let the team decide“, “meet the team’s needs“, etc. In complex orgs, there is NOT solely one team. There are many diverse teams and team types. Thus, as expected, their needs can, and do, clash.
To simplify the ensuing, one-way, BD00-to-you discussion, assume the existence of only three different team types:
Just like an individual must sometimes relinquish/suppress a personal need(s) for the greater good of the team, a particular team type must sometimes eschew one or more of its needs for the greater good of a different team type. In darker times, sometimes ALL teams must sacrifice some of their needs for the greater good of the “whole“. After all, if the “whole” goes bust, then all the teams being sustained by it go bust too. In a robust org, the converse is not true: if one team fails, the org will live on.
Is it possible to simultaneously satisfy every single need of each individual, each team, each team type, and the meta-physical “whole“? Since some idealistic people seem to think so, I suppose so – but I’m highly skeptical. The universe has always been, and always will be, gloriously messy. Because of the unavoidable human diversity residing within and across team types, a delicate give-and-take balancing act is necessary to keep the whole intact. Sometimes I gotta give to you and sometimes I gotta take from you. Sometimes you gotta give to me and sometimes you gotta take from me.
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.