Designing for Collaboration

I recently heard an executive (let's call her Ms. Foo) stress that collaboration is the key to success, and in order to collaborate effectively, a company needs to ditch the ubiquitous corporate artifact - the cubicle; therefore, (here's her hypothesis) eliminating cubicles and replacing them with an open floor plan is best for our organization. As further support for her hypothesis, Foo also has said that the cubicle is the epitome of a closed corporate culture and that high-performance companies (e.g. Apple, Facebook, Google, and Twitter) don't have cubicles.

As an exercise in critical thinking, let's quickly examine Ms. Foo's arguments - by first examining the argument for fallacies and then examining the veracity of the statements can we determine whether or not Ms. Foo makes a valid argument.

Let's first examine Ms. Foo's argument that 'collaboration is the key to success'. In its present form, this argument is clearly a sweeping generalization. Even if the statement were qualified to her own organization in the more precise 'collaboration is the key to our success' it's still arguably not precise enough and is not as precise as would be "collaboration is a key to our success". By increasing precision we can easily see that maintaining the argument in its presented form also creates a false dilemma.

Let's next examine the statement that 'the cubicle is the epitome of closed corporate culture' (and the connotation that such a culture is not what Ms. Foo wishes to represent). To better examine this, we will ignore the hyperbole and better express the argument as 'closed corporate culture promotes cubicles' - for certainly the epitome of 'closed corporate culture' would be a office door - or at the very least, something that can be physically closed. I would put forward that although Ms. Foo's original argument is a lightly veiled guilt by association, our restatement of her argument is clearly an example of such a fallacy.

Let's next take the statement that 'high-performance companies don't have cubicles'. Even if the statement is factually correct, and I am not in a position to argue that it is not, it still remains an argumentum ad populum. Perhaps what Foo intended was to present evidence that 'high-performance companies' have implemented a collaboration-promoting floor plan and found it beneficial. If this argument is intended as evidence, let's restate it so that it may more closely represent the evidence she intended - let's instead say high-performance companies have implemented an open floor plan and have seen an increase in collaboration.

Even though our more semantically precise argument doesn't fall into the argumentum ad populum, such changes in environment design are seldom executed under the strict controls normal experiments fall under and without control groups it is typically impossible to determine the veracity of the premise. Without demonstrating a causal relationship, the argument is, at best, subject to cum hoc ergo propter hoc or perhaps to post hoc ergo propter hoc.

It is clear that Foo's arguments are fallacious; however, that does not mean that the conclusion (that open floor plans are best for her organization) is necessarily false, simply that it is unproven, so let's continue the exploration.

There are additional problems with Ms. Foo's proposition; for example, it's rife with ambiguity. Perhaps by clarifying this ambiguity we can come to a restatement of the argument that is not fallacious - one for which we can examine the veracity.

First, it's not, generally speaking, as if a person chooses to either collaborate or not, but rather they choose, consciously or subconsciously, the degree to which and manner in which they collaborate; "collaboration" is not an all-or-nothing one-size-fits-all proposition. Further, Ms. Foo uses the term success without actually defining how success would be measured. Success may be defined as high productivity, as it is in many cases, or high innovation, or perhaps high engagement among the employees.

Ms. Foo's original argument might therefore be restated as collaboration in the manner I understand it is one of the keys to what I define as success for our organization; a floor plan that does not use cubicles, such as those employed by Apple, Facebook, Google, and Twitter, creates the type of collaborative environment I desire; therefore, eliminating cubicles and replacing them with an open floor plan is best for our organization. This restatement clarifies many of the points of ambiguity, yielding a much less fallacious line of reasoning; however, it also makes Ms. Foo sound a tyrant and generally undesirable boss.

I should point out at this point that I've not ever been to any of the companies classified as 'high-performance companies' and cited by Foo, nor can I say reliably that collaboration is not a key to success for her company. I can say that I have, in more than a couple of decades in the industry, worked in a variety of environments - everything from 'open floor plans' to an office with a door, and while I would avoid a hasty generalization, or other fallacy, there may be other factors Ms. Foo has not considered.

In my experience, each organization in which I have worked has had a variety of concerns that weren't related to collaboration that influenced the work space configuration decisions. The most pronounced concern has typically been security. My experience has been that the greater the need for security, the more restricted the work space is. Basically, in the work environments where security was highest, my workstation was behind a locking door and few people had access. Collaboration within environments with strict security is, undoubtedly, lower as knowledge and activity is compartmentalized; conversely, collaboration within environments with lower security is higher.

I would also say that I am generally supportive of collaboration - in fact, I would put forward that the teaching method named for one of the world's most famous philosophers is based in collaboration between student and teacher. In my opinion, it could easily qualify as a key to success in many organizations.

With those qualifications being disclosed, I'll continue, using, instead of Ms. Foo's original argument, the restated argument, and looking to the veracity and whether or not it follows from beginning to end.

First, I believe there is little room for doubt that physical environments can affect collaboration. The argument that a floor plan that does not use cubicles facilitates an open and collaborative environment may be true. However, possibility is not actuality, and I do not believe that an open floor plan is either a necessary or sufficient condition for collaboration.

There are, in my experience, a number of things that hinder collaboration. I would separate these hindrances into physical and non-physical obstacles. Non-physical obstacles typically include who can collaborate but also go beyond into how individuals are encouraged, or even allowed, to collaborate. In fact, I would posit that physical obstacles to collaboration, whether it be minor physical barriers, such as a cubicle, or more significant physical barriers, such as lacking a physical presence in a location (e.g. telecommuting), are less significant than non-physical obstacles in the face of technology, primarily because they are easily controlled. We can easily move into shared physical space in the case of cubicles or use email, phone (whether land-line or mobile), and instant messaging when lacking a shared location. In fact, organizations distributed across the globe typically use a combination of these tools and more to collaborate.

Since the non-physical barriers to collaboration - for example, a culture that does not value the contribution of specific individuals, whether that is because of their role in the organization or their position in the organizational hierarchy - are generally both more significant and more difficult to address and control, these issues should be addressed first. Seeing a physical environment as the obstacle to collaboration is a red herring, especially considering the number of methods available to work around physical environments. Further, because the features of a physical environment that affect collaboration can so easily be bypassed, we might conclude that if those features affect collaboration, and it hasn't been demonstrated that they do, that result is desired by at least one party to the collaboration. In other words, the processes for collaboration must be addressed prior to the environmental issues that may hinder collaboration, in part because it is quite possible that the very environmental issues seen as obstacles to collaboration may serve another purpose within the organization.

As an example, lets assume for a moment that one party in our 'collaboration' model has a constraint that creates an inverse relationship between a success and interpersonal interaction. If such a constraint existed, would it not follow that productivity would be improved in those situations where the amount of interaction was controlled? If physical barriers are easier to overcome - to manage - would it that factor not make it the preferred control? If we can see an affirmative answer to either of these questions, then is it not a simple matter of asking ourselves "can such a constraint exist?" The answer to that question is a definitive "yes" - AD/HD is a physical condition (and an ADA protected class in the US) that creates an inverse relationship between many measures of success and interpersonal interaction.

We've seen how this argument applies to cubicles, but how might the same general thought process apply to another collaboration-reducing environment, telecommuting? It is in this question that we will demonstrate the importance of the ambiguity of the word success as well as collaboration.

We can be certain telecommuting is a greater barrier to some forms of collaboration than cubicles, because at a very minimum the accidental interaction while moving through shared space is no longer available and intentional interaction must be attended to in greater detail. It seems after a two-month silence that perhaps this collaboration was what Marissa Mayer intended to address rather than productivity.¹

In making statement that telecommuting is a barrier to face-to-face interaction she has, to some degree, stated the obvious. However, she goes on to claim that people are more collaborative when they are together - in itself perhaps not a wild claim - and that it follows that they are more innovative. It is unclear whether this last statement is wishful thinking, a hasty generalization, an instance of post hoc ergo propter hoc, or an evidence-based claim.

Mayer clearly defines success as generating ideas (product development) rather than delivering on those ideas (productivity). By defining success, not as productivity - which has been the generally accepted measure of success - but as the generation and conglomeration of ideas, Mayer may have made a potentially workable argument for a direct relationship between what she means by collaboration and success; however, it is not a foregone conclusion.

If we define success as the generation and conglomeration of ideas, it might seem reasonable that we ought to look to increase collaboration; or at least interaction, including accidental interactions; however, we ought also recognize that the increased interaction comes at a cost. Further, we ought also recognize that the cost we pay in one area may not show a benefit in another. For example, it would be possible to decrease productivity without increasing collaboration or the generation and conglomeration of ideas.

Finally, even if the elimination of all physical barriers increases collaboration, which has not been proven by either Ms. Foo's arguments, or Marissa Mayer's, does it follow then that the increased collaboration is good for an organization?  Not necessarily, and that's where the design comes in. Without adequate design, one that balances the cost against the (real or perceived) benefits, increasing collaboration is destined to fail; otherwise, edicts intended to promote collaboration leave organizational members who have little chance to contribute to the discussion feeling disenfranchised and generally dismissed by a tyrant, and that environment is definitely not conducive to collaboration, or in fact anything other than self-protection and evasion.

Notes

1. Marissa Mayer Finally Addresses Work From Home Ban

What kind of engineer, indeed.

Several of my friends and colleagues have tweeted and otherwise commented about a post on the extremely knowledgeable Nick Zakas' blog.

I have a lot of respect for Mr. Zakas, and often enjoy his blog posts, learning something each time I visit, and this post was no exception. Unfortunately, there is also a point with which I don't agree...but it's not really Mr. Zakas' point. He says,

If you stop and think about it, writing code is something that a lot of people do. You can hire someone cheaply out of college to write code and it may not be as good as an experienced software engineer, but if it’s close enough, that’s usually all you need. So if your programming acumen is the only thing that you focus on, you aren't improving your position in the company. What matters far more are the soft skills that you have along the way. Do people enjoy working with you? Do you add something over and above your coding skill?

First, to Mr. Zakas' point, there are a lot of people who can code...but there is a potentially significant difference between "close enough" and "correct". With "close enough" your revenue most likely will not be zero, but it will also likely not be as much as it would with "correct"...and in some situations, "close enough" may be nowhere near close enough. If we're talking about a web page that responds in 8 seconds instead of 4 or 6, that may be one thing (though you might want to see my earlier post about speed in websites, Faster, faster, faster) but if we're talking about real-time or life-critical software, is "good enough" really good enough.

Still, Mr. Zakas is correct in that our reputation is important...but therein lies my problem, and it's demonstrated to a degree by those Peter Hinssen refers to in Will the real CIO please stand up - individuals who associate responses to the phrase 'IT departments' which are "wonderfully colorful comments such as 'arrogant', 'out of touch with reality', 'language of their own' and - increasingly often - 'hopelessly out of date'."

Are there engineers who are reasonably considered "arrogant" or "out of touch"? Certainly, and, I suppose if Mr. Zakas' post were geared toward those engineers alone, we might not have anything to discuss. Note, however, that Mr. Hinssen's post discusses the prevailing attitude. If we see "arrogance" and "hopelessly out of date" as the status quo, then I would posit that Mr. Zakas' advice to adjust our attitude addresses a symptom of the underlying problem without addressing any of the underlying issues.

In part, the prevailing attitude - that we are arrogant and out of touch - is our fault as software engineers. Whether we write software for the World Wide Web, smartphones, or desktops - we have, to some degree, failed to convey our value to the organization. Often we do speak a language of our own, and life would be much easier (from the perspective of those who see us as arrogant and out of touch) if we would just communicate more/better/the right way - if we would stop being so out of touch - if we would stop seeing ourselves as so valuable to the organization - after all, the contribution of an engineer is not that significant because "writing code is something that a lot of people do" (emphasis mine).

As a User Interface Engineer (or web developer, if you'd like), I often hear comments similar to this - comments about how someone's teenage relative can build a good web page. While there are, of course, prodigies, the amount of engineering that is required to create the best web page is significantly greater than the skill level held by general practitioners, as is the amount of engineering required to create the best software for other media. I would posit, therefore, that our challenge is not as much improving our soft skills (though every engineer I've met would benefit from such development), but rather conveying our value to the organization in a meaningful way. To that end, as a counterpoint to Mr. Zakas, I would commend a quote that Baskin-Robbins used to hang in their stores: "there is hardly anything in the world that someone can't make a little worse and sell a little cheaper - and people who consider price alone are this man's lawful prey."¹ 

There are a number of issues that might be discussed when an organization perpetuates a culture similar to Mr. Zakas' comment above (that people who code are a commodity) or similar to those Mr. Hinssen references; however, one of the most significant is that organizations which learn to accept "close enough" when it's less expensive incur technical debt that becomes deadly. Further, the effect such an attitude has on morale within the IT department can be equally as deadly as mounting technical debt.

There is, in my estimation, another side to this story. In the face of significant potential issues, such as creating code that's "good enough" under one estimation and not another, mounting technical debt without having resources to address it, and demotivating personnel, there is also the thought that perhaps the perception of engineers as weak in soft skills, arrogant, and out of touch, is mistaken. Perhaps, just perhaps, those engineers are instead are significantly different than other employees.

Perhaps these engineers are not arrogant and out of touch. Perhaps there are weaknesses related to their soft skills, but if we, instead of operating from the assumption that what these engineers do is something that a lot of people can do, operate from the assumption that what these engineers do is something that few people can do, and that they are therefore in a different realm than others, might we see their "arrogance" as an indication they have a different understanding of their capabilities and the situation? Might the perception that they are "out of touch" be due to the manner in which they, in their different world, relate to those outside  of their area of expertise.

Let us consider then, the possibility that their "arrogance" and being "out of touch" are, at worst, simple weaknesses in their soft skills. What is the best advice? Certainly Mr. Zakas' advice is good, and traditional - work on your weaknesses. However, is that really the best way in which these engineers can contribute? In this consideration, I would offer the following advice that Dr. Donald Clifton gave his son: "your weaknesses will never develop while your strengths will develop infinitely."²

Let me be clear - the best advice the creator of the Clifton StrengthsFinder, Gallup's own online psychological assessment, could offer his son, was to build his life and work around his strengths rather than try to fix his weaknesses. For Dr. Clifton's son, and many engineers, Mr. Zakas' words, and in fact the words of those who brand us as "arrogant" and "out of touch" would have them "fix their weaknesses".

In this, I would posit that rather than engineers spending time fixing their weaknesses, that they spend time using and developing their strengths, and that management (at all levels) spend time seeing and celebrating diversity and the value it brings. I understand this is unconventional wisdom, but perhaps, just perhaps, this is a new age - an age in which each of us can contribute to our fullest.

What kind of engineer do I want to be? One that develops my strengths infinitely.

1. This quote is attributed to John Ruskin, though there is some debate about whether or not that attribution is valid.
2. Reported in a post by his son.

Fear is the birth of cruelty and the death of reason, wisdom, and finally, action. (Robert's Rule #26)

Fear, as our 'leaders' have discovered, is a powerful motivator. For most people, one of the most powerful fears is of losing their job, in fact, for some people, the fear of the loss of their livelihood is even stronger than their fear of death, because it means something very significant to those who depend on them. Because of the power of this fear, employers the world over become some of the most powerful entities known. However, this fear comes at a price, for fear is the birth of cruelty.

When you, as a manager, threaten someone's job and engage this powerful motivator, your 'direct report' will likely tow-the-line. They will likely become quite complacent. They will also likely quit innovating, start protecting their assets to the detriment of the team, and start looking for a place of employment where they believe they will be respected, which means their productivity will generally plummet and they will become a drain on morale. In short, what you will have created is a negative reinforcement cycle that will likely spiral out of control.

On the other side of fear, however, the lack of fear is an equally strong motivator. The lack of fear can be the result of either having nothing more to lose or a true feeling of safety.

The lack of fear that is the result of having nothing to lose - that finds its origination in desperation - is dangerous in the extreme, as The Art of War notes. It is the recognition of this fact that has led companies to treat terminated employees as criminals as they are escorted from the building, often without even being given access to their personal effects. The creation of this type of 'enemy' is a mistake of the highest order and you should always try to maintain the appearance that even those discharged have something more to lose. Helping them move on to another position (if that is at all possible) is a good start. After all, just because they don't fit in with your organization that does not mean they would not fit in quite well somewhere else. If you can honestly, objectively review their contribution you will (nearly always) find some benefit they provided to the organization that you can leverage as they look for another position.

On the other end of the lack of fear spectrum - when a person feels safe in their job - people are more likely to take risks, stretching and growing. They are also likely to innovate, be more relaxed and positively affect team morale, in essence become a powerfully positive asset. It is the creation of these positive reinforcement cycles that we need to create. One of the most powerful effects of these positive reinforcement cycles is the energy they contribute to the team, as study after study has shown that 'winning' begets 'winning' and nothing so strongly counters winning than fear and trembling, because fear is also the death of reason, wisdom, and eventually, action.

Trust everyone at the table, but cut the cards anyway (Robert's Rule #18)

[Tweeted 2011-06-06]

Living in an area where there are multiple casinos within a short drive or a long walk, I've learned to see some things using gaming metaphors. One of these metaphors is trust everyone at the table, but cut the cards anyway (Robert's Rule #18), and if you are an empiricist like Hume, then this rule will automatically make sense.

How does it apply to work? First, if you are not able to trust your colleagues, work (and probably life) will be miserable. Of course the reverse is also true; trusting your colleagues will go a long way in making work not be the worst part of your life. In fact, I've had some jobs I should have hated because they were such a poor fit and yet I didn't because of my colleagues.

Second, not only will the inability to trust your colleagues make life miserable, it will be very difficult to accomplish what you need to accomplish as well. The amount of time you spend countering the machinations of office politics in a hostile environment will outweigh whatever other successes you have. In addition, those times in which you don't succeed your discomfort will be worse because of the negative self-talk that comes out of the lack of trust and your assumptions about yourself.

Of course, this doesn't mean that you should just blindly trust. After all, your trust can be pretty easily misplaced, and this is your livelihood we're talking about here. You can't just go about willy-nilly assuming that everything your colleagues do and say is true, and even a series of lucky guesses ends sometime, which is a very good reason to confirm what you believe to be true.

Of course all of this is to say trust everyone at the table, but cut the cards anyway.