collage of magazine covers
Take a step back in history with the archives of PragPub magazine. The Pragmatic Programmers hope you’ll find that learning about the past can help you make better decisions for the future.

FROM THE ARCHIVES OF PRAGPUB MAGAZINE MARCH 2019

Principles for Large Organizations: An Invitation to Brainstorm

By Tim Ottinger

PragPub
The Pragmatic Programmers
13 min readAug 4, 2022

--

Every discussion you have with your boss is really a discussion about your position.

https://pragprog.com/newsletter/
https://pragprog.com/newsletter/

I was speaking with my friend Bryan who, like myself, does a lot of work with very large organizations. Many of them are great places and have a sincere interest in being wonderful places to work with wonderful people. Sometimes, though, they struggle.

In considering the nature of their struggles, I realized that I’ve collected or formed some observations of dynamics and I’ve not really vetted them all publicly. I’d like to take this moment to think out loud and, with kindness and curiosity and empathy, see if we can develop and refine these observations— or possibly strike them entirely if they seem utterly false.

Please join me via comments or emails (t o t t i n g e @ g m a i l . c o m or t o t t i n g e @ i n d u s t r i a l l o g i c . c o m) to let me know what you think about these observations, what I’m missing, and what I can do to fill out the set better. Just remember, this is about curiosity and systems — I’m not here to tear anyone down.

Glass-front building
Photo by Patrick Schneider on Unsplash

Dunbar’s Number

Researcher Robin Dunbar noticed that primate “tribes” have a rough maximum size after which they can no longer maintain vital relationships. When primates exceed this number, the tribe splits. It doesn’t matter what events trigger the split, it’s more or less inevitable that the split will happen.

Smaller primates tended to have smaller tribes, whereas others seemed to tolerate a larger tribe size.

Dunbar discovered a correlation between the surface area of an animal’s brain and the tribal size of the species. This correlation seems pretty strong and has good predictive power when applied to other species of primates.

By extension, Dunbar reasons that a human “tribe” can only have about 150 members or so before the tribe splits.

In many small-to-medium-sized businesses and volunteer groups, especially churches in the U.S., this is referred to as the “200 Ceiling” because most organizations split when they have around 200 members. It takes different skills and organizing principles when an organization is so large that not all the members can all know and trust each other well, and keep up on each other’s lives.

Each individual in the organization has other vital relationships besides those in the organization. Many “slots” are consumed by family and other organizations. Most of us can’t really work in teams of 40 or 50 comfortably, let alone 200, 500, or 8,000.

A corporation is often far beyond the “Dunbar number.”

It may be an essential understanding that corporate life is ruled by Dunbar’s number; with the constant issue of working with people who are not “in our tribe” — with too many people and too infrequent an association to create and establish trusting, close, nurturing bonds.

Corporate life takes place at a distance for most people, once you get past their local group. Note that a “team” on an org chart may contain members of entirely different tribes, and their split-membership may put them at odds with each other or at least make it hard for them to establish and maintain any meaningful relationships.

The Law of the Second Floor

The “law” (not really a law, more of an observation) of the second floor builds on Dunbar’s Number by stating that “generally, no person two levels above OR below you on an org chart really understands what you do for a living.”

The programmers and testers building a product don’t really understand the life their grand-boss is living. The distance is too great, which puts the grand-boss into a different tribe. The grand-boss and the front-line team deal with different problems and are all too busy to develop a deep understanding of each other.

In the “trenches” where all the various kinds of developers work, management tends to be a remote “them” who are disconnected from the nature of the daily work. Their primary concern seems to be increasing workload and cutting costs. Policies seem arbitrary and fashion-driven, or else driven by political self-interest.

Likewise, up in the executive suite, it is quite hard to remember that the front-line employees are meaningful human lives worthy of individual care and dignity and respect. They all start looking like fixed expenses, sales numbers, say/do ratios, or other similar aggregations of numbers. There is a strong and growing suspicion that they are stealing money by wasting time and supplies (further reinforced by slipped estimate-driven schedules).

This isn’t by choice but is a problem of scale and social distance. After all, those remote persons are not the people we interact with; they are the people who interact with people who interact with the people we interact with.

You may have to read that last sentence three times.

By the law of the second floor, dehumanization of remote bosses and/or employees tends to be the norm. Attempts by individuals to pierce the levels and establish human contact tend to be treated with suspicion and distrust.

The Presence of the Secondary Topic

People work hard to acquire a position in a company. They pursued internal contacts or prepared eye-catching resumes and cover letters. They went out of their comfort zone to interview and submit to layers of filtering in order to acquire a position with the company. They probably turned down other opportunities with other companies. Editor’s note: This paragraph was revised by the author for clarity, and so differs from the original publication.

That position is important. Eventually the work done by individuals in a corporation becomes a secondary concern. The primary concern is to maintain or improve one’s position in the organization.

While it’s not politically appropriate to speak in those terms while inside the organization, this concern is the secondary topic in most conversations that take place across hierarchy levels.

The Presence of the Secondary Topic means: “Every discussion you have with your boss is really a discussion about your position.”

The subtext of the conversation is overloaded with questions: Do I seem like deserve to be here? Is it clear I am doing my part? Should I get promoted? Is this a reason I might be dismissed? Do I look redundant? Am I crucial? Do I get to stay here?

Because the boss is “of a different tribe” and has a strong influence on how or whether we will be perceived in our organization, and because the organization has a direct influence on our pay and social position, conversations always have a subtext.

A software team can miss a release date, can release bugs, and still retain their places. However, one hears stories of people being released for careless “career-limiting moves” (CLMs, they are often called in the boardrooms). Projects and positions can evaporate for political reasons. This creates a sense of fear and vulnerability in people when they are speaking to the people above them in the official hierarchy.

This is frustrating to all managers and to all employees, and seriously gets in the way of discussions about the work, tactics, strategy and performance of the company.

📝 Note: In early 2019, Zach Bonaker suggested referring to this as “role success,” a term which I heartily endorse. Note that role success is independent of organization, team, or customer success in many (pathological?) cases.

Singh’s Inevitable Avoidance

Ashok Singh suggests that when organizations don’t know how to solve their problems, they will tweak their process to accommodate their dysfunctions.

A company can’t afford to quit operating, nor can it afford to operate unprofitably. Therefore, it will maintain operation the best way it knows, even when that way is painful or unpleasant or even self-defeating. We can’t ask people to behave better than they know how to behave, or produce more than they know how to produce.

So when there is a problem, we route around it. It’s a wonderful testament to human ingenuity and flexibility. But it’s also another way to stockpile pain until it all blows up down the line.

Why do organizations tend to have quasi-agile-like processes? Because they have to route around all the dysfunction that is associated with working beyond Dunbar’s number, across the 2nd-floor law, and in light of the secondary topic.

This process work isn’t easy. It’s not like people are working with only their twelve best golfing/drinking/running buddies. In a large company, there will be issues that seem to be (and probably are) too large to address at the moment, and so they are avoided for a time.

The important thing to remember is that “a problem deferred is not a problem avoided.”

This problem was mentioned (related to scrum) at the scrum.org site, and was described as “scrumbut.”

What is ScrumBut? ScrumButs are behaviors where the team is doing “scrum, but” still doing things that are outside of the rules of scrum and clearly not within the intention of that framework. It may be scrum but with no self-organizing teams, scrum but with waterfall-like “design sprints” and “hardening sprints”, or scrum but with no sprint goals and no contact with the product owners.

Each ScrumBut is change avoidance. A ScrumBut retains problematic behaviors by modifying scrum to tolerate the behaviors that scrum (and all other agile methods) are intended to replace.

I suspect that the majority of organizations that claim to use scrum do not, in fact, use the framework and never have actually tried to use it. Rather, they borrow a few terms and practices and muddy the water with a large list of ScrumButs as described in The Daily Meeting:

Each of the agile terms was (naturally) mapped onto concepts that the organization already understood. They became a kind of euphemism. Ideas that didn’t map to existing practices tended to be dropped.

Editor’s note: The four paragraphs above were revised by the author for clarity, and so differ from the original publication.

While this describes SIA with reference to scrum, you will find the same problem regardless of the process, practice, or any other change in the du jour operating model of the organization.

This is further described by others (including Joshua Kerievsky) as “organizational antibodies.”

Preserving a problem to avoid upset is common and is likely to be related to the principles listed above. It is an unintended consequence of preserving an organization’s current culture. And on that note: distilled culture.

Distilled Culture

A company’s processes are a distillation of the company’s culture into a set of rules.

These rules may directly contradict the company’s stated values, in which case the stated values are ideas that some leaders have hopes to aspire to (an “end state”) and the actual policies are an indicator of the culture to date (the “beginning state” or “late status quo”).

Sometimes, the stated values are a smokescreen, though, and attempts by people within the organization to move policy decisions into alignment with the stated values can be met with disciplinary measures or dismissal (see Secondary Topic).

There are people in the organization who want to move the company in the direction of values, and who have the authority to approve or support such attempts, but they may often be divided by more than two hierarchical levels, or worse have no knowledge of the people who need the support and encouragement.

Process Theater

A process is successful because it is declared to be a success. This is the soul of process theater.

Organizations spend uncounted dollars and hours on maintaining the illusion that their processes are being followed and that they work. The more onerous and comprehensive the process, the more money and time is poured into making it look good.

This follows on the understanding that a company’s process is a distillation of the culture — it is “how things are done,” “how we aspire to do things,” and “how we keep from stepping on other people’s feet.”

A process that has enough heft will require tooling, administration, and enforcement. Often the care and feeding of a process will create full-time positions for a number of people. Changing the process causes the company’s valuation of those people to be questioned (presence of secondary topic).

If there are jobs on the line and significant investment to date (see “sunk cost fallacy”), then it becomes very important to the organization that the process is seen as successful and is maintained in place. It doesn’t have to actually be so, it is assumed that the company is not foolish enough to have invested millions of dollars in a process that doesn’t really work.

The goodness or badness of the process seems to be inconsequential. A bad process or a good process will be spun to look successful. Nobody will validate that the process is actually helpful, because measuring the ongoing investment seems an act of sedition. The process IS. It is unquestioned. It IS because it MUST Be. It is the distillation of our culture.

The more heavyweight, comprehensive, and complete the process is, the more cost and time are poured into making it seem to work. I often credit this feature with the widespread “success” of waterfall methods in the 80s and 90s, and with the “success” many companies report with their complicated scaled agile methods.

This makes a process change an emotionally, culturally, and financially difficult proposition for a large organization. This is true even if the present culture and the process directly oppose the purpose of the company. For example, most of the policies and processes of software organizations focus on preventing the release of software.

I am not declaring that organizations are morally bankrupt, dishonest, and unchangeable. Please don’t take this as an indictment.

But rather, this is a constraint on our ability to create change and will inform how we go into organizations. Don Gray and Esther Derby (Coaching Beyond The Team) suggest that we will have greater success if we honor what has gone before. Without surrendering our intention to make positive change, we should examine what the organization has done and what they aspire to do. We should recognize the heroes of the last transformation and the people who keep the lights on.

We can recognize the human costs of changes and not be cavalier toward people who might suffer due to the changes. We can seek to find new ways to integrate our people into the new processes. We can recruit them to aid in the change. We can try to “make them awesome” rather than make them redundant.

And also, we should watch ourselves. We may be guilty of the same spin-doctoring. Are our processes and process changes really making the company more successful, or are we merely getting more people to act their part in our theater production?

The Trust Transaction

The trust transaction is the transaction of completing assignments well and in return having more autonomy and opportunity.

  • When trust is low, governance is necessarily high.
  • When trust (delivery) is particularly high, governance is unnecessary.

Many organizations have very little trust or delivery until a facilitator with authority helps them to begin negotiating this transaction. Often teams need “enough trust to grow into” and this comes by trimming down the amount of per-person governance and bookkeeping. In return, if they deliver more often and with a higher level of transparency, it is easy to afford them a little more trust.

In time, if there is enough progress or success, the managers are happy to treat a team as an atomic, autonomous unit. If, however, teams or individuals “go dark” (work is invisible) then governance is increased and management tends to micromanagement.

This is only natural in light of the other principles in this blog.

Power of Agreements

Finally, after all of these things are considered, the most important breakthroughs may come by realizing that policies and structures and all the elements of culture are not natural laws or government-mandates.

Ultimately, how organizations work is really just a bunch of agreements made by people.

It’s all made up. None of it is real. Some of it is quite useful.

If a company is made of agreements, then it’s up to the people working in it to ensure that their agreements were consciously-made and remain beneficial.

Many people would be happy to endure the tirades and public shaming of a dictatorial boss who would also make them rich and famous. It’s a transaction. Others are happier working in more egalitarian environments and wouldn’t stand for it.

Some people work in organizations where self-actualization is a primary cultural more, others where people are resources to consume. Some people value working on powerful teams, but others where they’re left alone to do their work as they choose without interactions. It’s all a set of choices.

But it’s all made up.

Possibility thinking begins with the understanding that an organization is pretty much what its people choose to make it. It grows and develops according to what its people are willing to trade, and what they’re willing to trade for it.

About the Author

Headshot of author Tim Ottinger

Tim Ottinger is the originator and co-author of Agile in a Flash, a contributor to Clean Code, and a 40-year (plus) software developer. Tim is a senior consultant with Industrial Logic where he helps transform teams and organizations through education, process consulting, and technical practices coaching. He is an incessant blogger and incorrigible punster. He still writes code, and he likes it.

Cover of PragPub Magazine, March 2019
Cover of PragPub Magazine, March 2019

--

--

The Pragmatic Programmers
The Pragmatic Programmers

Published in The Pragmatic Programmers

We create timely, practical books and learning resources on classic and cutting-edge topics to help you practice your craft and accelerate your career.

PragPub
PragPub

Written by PragPub

The Pragmatic Programmers bring you archives from PragPub, a magazine on web and mobile development (by editor Michael Swaine, of Dr. Dobb’s Journal fame).