In the pic below, I prefer taking the low road over the high road.
So, now that you and your accomplices have labored long and hard to transform your standard org into a high performing org, you’re happy as a clam. Whoo Hoo!
But wait! What happens when you inevitably team up to do business with a standard org? D’oh! I hate when that happens.
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.
In “The Politics Of Projects“, Robert Block rightly states: “People want products, not projects“. The ideal project takes zero time, no labor, and no financial investment. The holy grail is to transition from abstract desire to concrete outcome in no time flat :). Nevertheless, for any non-trivial product development effort requiring a diverse team of people to get the job done, some sort of project (or, “coordinated effort” for you #noprojects advocates) is indeed required. Whether self-organized or dictator-directed, there has to be some way of steering, focusing the effort of a team of smart people to achieve the outcomes that a project is expected to produce.
At the simplistic BD00 level of comprehension, a project is one of two binary types: a potential revenue generator or a potential cost reducer.
Startups concentrate solely on projects that raise revenue. At this stage of the game, not a second thought is given to cost-reduction projects – the excitement of creating value reigns. As a startup grows and adds layers of “professional” management to control the complexity that comes with that growth, an insidious shift takes place. The mindset at the top flips from raising revenue to reducing costs and increasing efficiency. In large organizations, every employee has experienced multiple, ubiquitous, top-down “cost reduction initiatives“, the worst of which is the dreaded reduction-in-force initiative. On the other hand, org-wide initiatives to increase revenues are rare.
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.
“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.
Fresh from Tom Gilb’s “Advanced Agile Practices” presentation, I give you Dave Rico’s 14 pitfalls of agile methods:
If you look closely at the list, the entries don’t just apply to attempts at agilization. They are daunting challenges for any aspiring corpo change agent who wishes to make a sweeping change to “the way we develop products“.