Distributed software development (DSD) is a reality in the technology-driven global world we live in today. It is one of those trends that will accelerate much further after Covid-19.
Successful companies and organizations who cracked the DSD code employ common best practices and gain market leadership from the benefits of making it work effectively and avoiding inefficiencies. Those companies are able to offer their employees more flexibility, save R&D costs, enjoy a diverse workforce, capture global markets, and produce higher-quality software products.
Software development is a difficult endeavor with many challenges, but distributed software development simply magnifies those challenges, particularly in strategy, communication, coordination, product architecture, management techniques, and infrastructure.
This narrative expands on the definition of DSD with examples and summarizes the top best practices employed by successful companies to design and implement distributed software development with an intention that other companies can leverage.
If you just want the executive summary, you can jump straight to the best practices.
In This Article
Distributed Software Development Defined
You are a distributed workforce if your employees in the organization are working in different locations or sites. It was even suggested that people on different floors of the same building or within a distance of 30 meters apart are also considered distributed (see MIT paper and hierarchy of distribution levels in Microsoft Windows from binaries code check-in a paper by Christian Bird and Nachiappan Nagappan)
Why is that important? In a nutshell, we’re human, and things happen when groups of people collaborate and trust one another - that’s what companies are about.
There are many advantages to being distributed, but if the basic best practices are not in place and carefully considered, that’s when things become very difficult and potentially disadvantageous to a company.
Why Companies Use Distributed Software Development
Companies and organizations are distributed for different reasons. They may be outsourcing, the team may have grown through acquisitions, they may be distributed to capture market share, they may be seeking lower-cost geographies, they may be looking for diverse talent, or they may be a naturally born, fully distributed company/workforce.
It is observed in studies that when a team is fully distributed, or when they are all in the same place, they are better able to coordinate their work and collaborate - some of the known challenges outlined above tend to disappear, and collaboration typically goes more smoothly.
Company leaders that embark on setting up outsourcing operations or creating a second development site often fail without help if they lack the experience that provides them with the necessary tools and best practices. Many end up with failed initiatives on their hands, lower-quality products, excessive spending, and dissatisfied customers.
Badly designed distribution or excessively distributed teams often fail because they are assembled in a haphazard manner without regard to the factors that ensure success.
However, when teams are distributed, whether due to the effects of the team size or for other reasons, things begin to break down, fortunately, there are key lessons to leverage to avoid the potential negative impact.
Examples of Successful Distributed Software Development
Distributed development, at times, may seem easy and magical when looking at larger companies such as Microsoft, Google, Facebook, and Amazon and how their workforce is spread around the globe. But these companies follow some best practices, continuously work to address those challenges, and explore better ways of working as well as use technologies to allow them to do so effectively. Despite that, there are still inefficiencies but the margin of pain is concealed by their sheer size. Smaller companies cannot afford the same luxury.
While the latter are non-profit for the most part and motivated differently, they make a good success case. Collaboration efforts such as Wikipedia and open-source projects produced humbling collaborations that most of us cannot grasp. How does the community of decentralized 15,600 developers collaborate to produce something as unimaginably complex as Linux or 138,173 people document the world information in Wikipedia?
Success is not cheap nor easy; it takes time and effort. This is why those who have built distributed teams in the past are often skeptical when they encounter something along those lines “The solution is simple. We will just outsource to a lower cost center”. It’s a bit more than a shopping trip.
Product Development Requires End-To-End Collaboration
The days when software development was limited to defining some use cases and deploying a piece of software are long gone. Today, software development itself may have become easier with the availability of a plethora of platforms and tools, but developing software products is complex and includes a larger spectrum. Software product development has to consider the entire journey from how to build it, how customers discover it, learn it, buy it, use it, pay for it, and how it is being supported. Let’s examine the support aspect outlier.
We have all experienced great and bad customer service and know that when we reach out to a company for help, it is sometimes a gamble. In extreme cases, it is outright painful. We may expect everything from a generic canned customer service response with an absolute lack of ownership of solving the problem to the anguish that the feedback/question went into a black hole database. Compare that to a small, tightly-knit team in a company that is committed to its customers and is anxious to help solve their concerns. That’s also a symptom of weak distributed development - it’s not just about checking in code.
Alignment Is Critical For Successful Distributed Development
While the best practices are listed later, this one really deserved its own section!
Many believe that no one has fully cracked the code for how to make distributed development work. Perhaps some aspects of this are true, but luckily we have real-life examples of accumulated best practices showing when it works well.
The tip of the iceberg in that formula is one of the pillars of what makes marriages, partnerships, families, communities, and countries work. It’s called continuous alignment in a shared belief.
It’s challenging enough for a company to help their employees fully understand and align to a vision/mission; in a distributed setting, the effort has to be doubled; otherwise, the weaknesses get magnified.
Perhaps the best example comes from Yuval Harari in his Sapiens book about alignment, which he calls the “story.” The story unites strangers and prompts them to collaborate when they are unified by a common belief (i.e., vision/mission). The reason why this works well is that it sets the direction and allows disparate groups to execute with autonomy in large groups. It is difficult to control the small execution details of individuals, but accepting the average execution of the population allows growth. Many small companies are unable to grow due to over-controlling founders who fail to employ leadership vs. dictating tasks.
Here are a few abbreviated excerpts from Sapiens:
“Two Catholics who have never met can pool funds to build a hospital because they both believe in God. Two Serbs who have never met might risk their lives to save one another because they both believe in the existence of the Serbian nation, the Serbian homeland, and the Serbian flag. Two lawyers who have never met can combine efforts to defend a complete stranger because they both believe in the existence of laws, justice, human rights, and money paid out in fees.”
“Before the Cognitive Revolution, forager bands couldn’t band together in anything bigger than the Dunbar number of 150, the maximum group size Sapiens can organize to (which is still true today). Sapiens can’t remember more meaningful relationships than that, which means they can’t trust strangers. The Cognitive Revolution solved this problem with the invention of shared myths.”
So, yes, as corporations, business people, and investors, we can leverage those same best practices to take full advantage of the benefits of distributed development while not suffering from the disadvantageous challenges.
6 Best Practices To Setup Distributed Development for Success
Intentionally designed distributed development works, but to be successful in a distributed development setting, you just have to do the things you already do in your company, but better and be ready to spend more money if you are serious about success.
Here are the 6 common best practices for companies that are successful with distributed development execution - assuming the intention is to build long-lasting development hubs.
1 - The Model
Decide on the model that works best for your company and teams. This may appear as a binary decision, but far from that. The effort requires careful consideration, design, and potentially multiple iterations and continuous improvements. Companies typically hire a 3rd party to help them evaluate the most suitable model since this is not a typical or expected know-how within a business.
For example, you may choose to set up two equal hubs, a hub and spoke, or even a constellation model. Each is suitable for different situations and has different challenges.
Equal hubs will share business ownership and will both have strategic input, leadership, and autonomous decision-making. They may also be challenged by competing or misalignment leadership. A hub and spoke will split the strategic and tactical ownership and may have independent component ownership across sites to enable simpler collaboration. A hub and spoke can be challenged with glass ceilings for career progression and higher employee attrition rates.
The decision should also take into perspective the longer-term company roadmap plans. Understanding the various model employed and what is most suitable based on the software architecture in place and company goals is a critical first step.
2 - The Shared Belief (i.e., Vision/Mission)
While ensuring any team/employee in a given company has a full understanding of the company vision and mission, it is significantly more important and more work to ensure that distributed teams do. For example, regular executive events and communications that help align teams working together should be doubled along with any associated budget. The same effort will require travel, face-to-face visits, and more regular events in order to accomplish the same in a distributed steam environment.
3 - The Team Building
Aside from the vision dissemination and continuous alignment events, there are also human nature needs. It’s about how to simulate the “water cooler effect,” which is one of the ways of establishing relationships and improving collaboration. Teams and individuals who engage in activities together and forge deeper relationships work together more effectively.
This is often dismissed or underplayed due to the costs associated with it. For example, reciprocal team visits, group events, and individual visits, especially from management, are all means to accomplish this.
Another indirect component of team building is training and especially cross-cultural training in the event that the team is distributed across different countries or cultures.
4 - The Clear Ownership And Agility
In addition to the shared understanding of the vision and company direction. Another related but large consideration is “What each site will own?”. This one has direct implications based on the software architecture and quality. Software applications that are tightly integrated or legacy, for example, can be very difficult to develop in a distributed setting due to dependencies. On the other hand, satellite teams who work on independent components or on a modular architecture with minimal dependencies can be successful.
Clear ownership at the site level is an important consideration to be able to establish a clear identity. For example, this can be an entire product, a component, a market segment, etc. It has to be something that the team would eventually identify with and take pride in their contributions.
Regardless of the chosen mode, local leadership is important, but it may be different based on the model. For example, two equal hubs may share executive management with equal responsibilities, while a hub ad spoke might have director-level management in the spoke. However, a career ladder and middle management have to be in place with potential consideration given to employee glass-ceiling-related attritions.
Ultimately the autonomy and decision-making ability for what is being owned cannot be understated. An enabler for healthy decision-making and collaboration in an agile setting to empower individuals and teams to be in control of what they deliver and be accountable.
5 - The Collaboration Tools
Collaboration tools are enablers of successful distributed development. These should be carefully evaluated and rationalized from time to time to upgrade. Collaboration tools are a reality of life across companies today, but those tools needed for distributed development situations have to be a notch higher and work better. Companies often allocate an individual or a team to continuously evaluate, manage, deploy, and improve the toolset internally to ensure they do not get in the way of cross-group collaboration in a DSD setting.
The tools should cover end-to-end collaboration from chats, tasks, check-in, build, deployment, communication tools, productivity tools, storage tools, etc. Communication tools, in particular, require etiquette training, for example, to ensure that employees are aware of the best practices required in communication as well as cultural and timezone awareness, which might be assumed as basic common sense, but should not be taken for granted.
Social tools are another set that is not typically needed for co-located teams but make things much better and enhance collaborations. For example, some companies found success by establishing an “always-on conference room” or improving their AV equipment. Others use hallway monitors displaying the news, weather, events, and recognitions across offices. In addition to proprietary social tools, companies with a distributed workforce tend to make better use of social tools like LinkedIn to reinforce corporate priorities and vision.
6 - The Equal Benefits And Pay
Benefits are a competitive advantage for companies today. They compete to offer the best perks to attract and retain employees. While this is challenging enough when there is a single location, in a distributed development environment, the keyword is “fairness and equality” across sites.
Everyone must have the same or equivalent benefits. If you are in the united states, for example, you are likely offering health insurance benefits to your employees, but if you have a site in Europe, this is not a meaningful perk as everyone is likely to be covered. You can’t just cut it without alternatives.
National holidays across geographies, retirement plans, health savings, sports benefits, company picnics, and all other benefits have to be considered and tailored to each locality.
This may come as a surprise for some, especially as global and uniform as our world seems at times, money is not the only motivator for people in some cases. Of course, there is a min-bar, and everyone likes nothing more than to make loads of money - everyone wants that too. But the balance of priorities for individuals is sometimes different between cultures. Those small differences can be observed more in old cultures. From my own experience working and managing people across the globe, there were some hard-learned lessons about what motivation really meant in different cultures. Sharing a pint in London or a glass of wine with colleagues over a simple dinner in Bordeaux, a tightly-knit team feel in Tallinn with a great atmosphere sharing a Sauna, participating in local cultural events and activities in Shanghai, or displaying empathy to your colleagues in Cairo can go a very long way. Cultural training is a must!
Some even consider flexibility benefits such as remote work agreements, which are a very healthy setup for some companies. They allow employees to be more relaxed, acquire flexibility, and often save commuting time. Depending on where an employee lives, taking into account a 1.5-hour daily commute can be equivalent to as much as 2 weeks per year in time savings that can be spent with family or working. How does your company reconcile that?
Finally, the big question of equal compensation and establishing a fair and equivalent career ladder allows employees to get paid at similar rates based on the local cost of living index.
Intentional Distributed Software Development Works!
Team distribution is possible to be as effective as co-located teams if “intentionally designed” with the best practices implemented. It is not an easy endeavor. It takes time and it requires an investment and budget. Well thought out and well designed, it can be a competitive advantage for a company seeking growth or cost savings.
About the Author
Hazem has been in the software and M&A industry for over 26 years. As a managing partner at RingStone, he works with private equity firms globally in an advisory capacity. Before RingStone, Hazem built and managed a global consultancy, coached high-profile executives, and conducted technical due diligence in hundreds of deals and transformation strategies. He spent 18 years at Microsoft in software development, incubations, M&A, and cross-company transformation initiatives. Before Microsoft, Hazem built several businesses with successful exits, namely in e-commerce, software, hospitality, and manufacturing. A multidisciplinary background in computer engineering, biological sciences, and business with a career spanning a global stage in the US, UK, and broadly across Europe, Russia, and Africa. He is a sought-after public speaker and mentor in software, M&A, innovation, and transformations. Contact Hazem at hazem@ringstonetech.com.