Bertheau's Law

Remote Teams

Total Cost of Remote Teams

There seems to be a short-sided cost savings mindset correlated toward lower-cost technical resources located remotely to product definition staff and existing product development staff. This white paper describes some of the hidden costs related to those decisions and allows businesses the ability to capture total cost of ownership prior to execution of those strategies.


Table of Contents

Total Cost of Remote Teams

Brooks’ Law

Adding Resources


Bertheau’s Law

Software Development Lifecycle


Application of Bertheau’s Law

Communication Complexity Barriers

Remote Team Inefficiencies


Total Cost of Remote Teams

Without tight clear communication from stakeholders and customers to the staff defining and developing products, the odds of delivering a product that satisfies business needs within time and budget constraints are infrequent.

Brooks’ Law

Frederick Brooks authored a book titled The Mythical Man-Month1 in 1975 with a second edition published in 1995. The book was written as a result of his experiences while working at IBM and being responsible for IBM’s System/360 computer operating system.  

The challenges of that project experience allowed him to identify a few critical things that cause software projects to become late, and in an attempt to recover the late project what can cause them to become even later.

Adding Resources

The first item he discovered is related to the usual approach of adding resources to a late project. This situation is very common in commercial software businesses because revenue is forecast based upon project completion. Therefore when it becomes perceptible that a software project is late the natural tendency is to add resources to bring the project back into the timeline required too protect the revenue forecast associated with that project. Usually the date is the most unmovable item, with feature requirements the next unmovable item so adding costs, i.e. - team members is what drives this behavior. Mr. Brooks stated, “nine women cannot have a baby in one month” to illustrate that point.

Adding resources has proven to be a flawed strategy because technical resources are not homogeneous since it takes more than computer science skills to develop software products. What is most often lost with this approach is the business context, which is described through communication. The assumed homogeneity of resources and those resources not having the business context are the problem in this situation. A major component to that issue is related to the flow of material information to all the team members, and communication of relevant information is the substance to his findings. It is eventually realized that diminishing returns happen and often-negative returns are the true result of this method when it is employed.


The second key finding as stated above is related to the complexity of contextual based communication to the development team responsible for delivering the project. The flow of relevant information to all direct contributors of a software project is very difficult. As new team members are added the effort becomes geometrically more difficult because as you add more staff to a project team the flow of information has more communication paths to travel to maintain the same degree of product knowledge across all team members. Frederick Brooks described this observation through an algorithm, which is known as Brooks’ Law.

The communication pathways “C” are derived from the number of team members “n” in the formula shown here. Mr. Brooks had remote teams, which made the communication even worse than the formula he used to describe the communication issues observed during his career at IBM.


Equation : Brooks' Law

Bertheau’s Law

Remote teams and the communication complexity related to those teams are the focus of Bertheau’s Law;2 by the very nature of being remote communication efficiency starts to erode and breakdown. In essence Brooks’ Law describes the degree of communication difficulty increasing simply by adding team members to a project because the number of individual connection points between team members increases, referred to as communication pathways.

This perspective misses the essence of communication, that of actionable understanding of that communication, that is the intent of communication. The degree of efficiency, or degree of difficulty related to those communication pathways being effective.

Brooks’ Law is concerned with defining the number of communication pathways, while Bertheau’s Law is concerned with the quality of communication through those pathways.

Brooks’ Law and Bertheau’s Law are both concerned with contextual based business relevant information transferred to all team members who are responsible for defining and delivering the project. Remoteness causes erosion of the communication pathways; in essence can be viewed as adding communication pathways. Quantifying the problems associated with remoteness with regard to communication is difficult, however it is logical to build on or extend Brooks’ Law for that quantified description. Correlating an increase in communication pathways as a byproduct of remoteness accomplishes that quantifying problem.

Software Development Lifecycle

Traditional SDLCs mitigated communication breakdown by creating clearly defined written documents that prescribed everything up front of the project starting. The problem with this approach is the staleness of the information contained within those documents, as soon as they are written they become out of date. Clearly six months, nine months, or whatever the project duration happens to be; the documented product definition that was written, pre-project start are out of date with the customer needs and or market needs.

With today’s software development approaches clear communication is even more vital evidenced by the new SDLC models such as Scrum3 and other agile variants that are highly dependent on the team iteratively defining and developing the product. Those agile SDLC models have structured much more importance on the communication connection points because the development team4 along with the product owner are defining and developing the product together. These agile methodologies are highly dependent on collaboration with the team members versus the typical written documented artifacts of more traditional waterfall style SDLCs of the past. The newer SDLCs tend to be quite flexible with iterative development cycles and changeable requirements built into the SDLCs framework and structure.  


Since Mr. Brooks time outsourcing software development to remote teams has become quite common and has even spawned a new business market segment directly related to outsourcing product development activities. The primary motive has been to reduce cost as remote teams have a compelling cost savings as developing countries have a different wage structure. Bertheau’s Law attempts to quantify this new commercial reality allowing businesses to take total cost of ownership into account when deciding to undertake the use of remote teams, either internal remote teams or external remote teams.

Having an ability to realize the net change related to the decision, have the team in one-location verses two-locations that are remote to each other provides the framework to answer those questions so the actual tradeoffs can be better understood and made. As an example; the tradeoff of having the risk associated with a product that is less than optimal with regard to feature implementation versus the direct cost savings of development team; in essence, communication inefficiencies caused by remoteness provide direct cost savings however add risk to product fitness.

Application of Bertheau’s Law

Bertheau’s Law extends Brooks’ Law by considering the communication breakdowns attributed to a remote team and the actual items that make remoteness an issue for software development team effectiveness. As stated earlier Brooks’ Law’s observations state that communication erodes as team members are added simply because the number of communication pathways are increased. This erosion occurs as a direct result of the effort it takes to keep the entire team fully informed. The information cannot flow as freely as it did prior to the team size increase because the number of communication pathways increased in a geometric way to the number of staff added to the team. Bertheau’s Law builds on that concept and maintains the communication pathways measure is quite true and valid, and is postulating that disturbances in communication can be correlated to an increase in communication pathways. Extending Brooks’ Law, Bertheau’s Law calculates the communication disturbances with an exponent value applied based on the number of communication complexity barriers (CCB) that are present.

Brooks’ Law algorithm is modified by adding an exponent, “1.x” and defining “x” as variable based on quantity of CCBs related to the circumstance of the remote team’s complexion and structure. There are three CCBs therefore the exponent can be 1.1, 1.2 or 1.3, depending on how many of those CCBs exist for the software development project under consideration. If none of the three CCBs exist the exponent becomes 1.0, which is equal to Brooks’ Law therefore Bertheau’s Law is not pertinent and not under consideration for those circumstances as Brooks’ Law fully describes the communication breakdown the project team experiences.

Bertheau’s Law algorithm is shown here, the CCBs are not hierarchical but additive. The sum of the quantity of those CCBs that are present for a given project equal “x” of the exponent; e.g. – for a project where two CCBs exist, say physical remoteness and time offset the exponent value would be 1.2.

Equation : Bertheau's Law

Another way to describe this condition is to think of items directly related to communication inefficiency. The CCBs are describing inefficiencies in communication, they are:

  • physical remoteness; and    

  • time offset; and   

  • cultural difference.  


If the team structure produces one CCB that is a Level 1 condition, two CCBs are a Level 2 condition, and three CCBs are a Level 3 condition for the project team.  Bertheau’s Law exponent values are described below:

  • a Level 1 condition create an exponent value of 1.1; and  

  • a Level 2 condition create an exponent value of 1.2; and  

  • a Level 3 condition create an exponent value of 1.3; and 

  • no CCB conditions create an exponent value of 1.0 which equals Brooks’ Law.  

This approach allows the geometric nature of Brooks’ Law to be preserved and creates a very small exponential nature to Brooks’ Law; the exponential component is related to team remoteness.

Communication Complexity Barriers

CCBs are the primary elements used to determine the degree of communication a development team will experience. This section defines the CCBs and provides the guidelines on how and when to apply them.

Physical Remoteness

The development team needs to be in the same room and the product owner needs to be in the same building. If this situation is not present then the project structure causes a CCB physical remoteness condition.

If the development team is not in the same building and the product owner is not in the same campus you are loosing your communication efficiency. The ideal situation is where the development team members and the product owner have immediate and ad hoc/at will direct access to each other. A situation where the product owner is in the same building but the development team members are in the same room would be workable, that is efficient enough to exclude the “remoteness” measure.

This describes the degree of remoteness; that is the actual impediment to communication. Fundamentally, are you in the same room with your team members? Are you in the same building, campus, city, country, and etcetera?

We tend to think of communication as written and spoken, however there are many methods where communication occurs and body language is one of them. If the team conducts meetings from remote locations then we loose that part of the communication.

Time Offset

If the team is separated by more than three hours then there is a negative time offset component to the structure of the project and the team suffers a CCB time offset condition.

Time zones differences greatly impede communication. Humans are biological creatures and have a cadence based on daylight, given there are eight hours of a working day it is simply too difficult to have enough time overlap between the remote teams to facilitate effective and productive communication.

There are communication vehicles that are typically used to overcome the remote team collaboration problem; such as video conferencing, most of these tools are of poor user experience, which cause the meetings to be unpleasant and ineffective and really doesn’t mitigate the communication problem.

The time offset of greater that three hours present other problems related to not being able to dialogue during the stream of work activities. Two team members maybe working on the same work item, it is common when a particular piece of work is shared the communication happens many times a day supporting each other in that effort, this simply cannot happen efficiently when the time offset is that great.

Cultural Difference

When 30% of the team is not from the same geographical region, (defined as culturally same, not similar but same) the project team incurs a CCB of cultural difference condition.

If you are culturally different you are dealing with impediments to communication. Lets take a New York City person and have them try to have a conversation in New Orleans Louisiana at a local bar. The norms of New York City are drastically different than those of Louisiana, either person will not easily understand the nuances of the others spoken language. Even being raised in the same country and speaking the same language doesn’t guarantee or insure cultural sameness. The two maps5 below describe this condition.


Figure : Cultrual Difference; traffic circle, or roundabout, or rotary


Figure : Cultural Difference; crawfish, or crayfish, or crawdad

The failure to communicate happens on many levels and it starts with the spoken language and reinforced through the culture.

Similar but more obvious are when people are raised in different countries, often times that leads to one of the team members having to converse and communicate in their second language.

Remote Team Inefficiencies

The combination of any or all the CCBs can drastically alter the efficiency of the intent of the communication and that is the root cause of reduction in quality of product delivery measured in terms of; product fitness, product quality, product delivery, and product cost.

The inefficiencies are represented in the graph below.


Figure : Bertheau's Law Communication Complexity Related to Team Size

The graph above simply shows the non-linear negative effect remote teams experience as a result of one or more communication complexity attributes. The number of communication pathways greater than 50 and less than 100 are in the caution zone while over 100 communication pathways should not be attempted.


1 Frederick P. Brooks, Jr., The Mythical Man-Month, Addison-Wesley, Boston, 1975.

2 Bertheau’s Law is trademarked and owned by Pansophos Associates Limited.

3 Ken Schwaber and Jeff Sutherland, The Scrum Guide,, 2013.

4 For the purpose of this discussion the terms development team and product owner are described in The Scrum Guide. Development team referrers to anyone that is part of the development or creation of the product, the product owner is defined as the person responsible for the product definition.

5 Joshua Katz, a Ph. D student in statistics at North Carolina State University published maps based on research by Professor Bert Vaux and Scott Golder’s linguistic survey that looks at how Americans pronounce words; the maps can be found at this link.

<-- -->
Drupal SEO