The Future of Work Will Be Largely Distributed

Why You Should Build Your Organization as a Collection of Containers

Today, the question of building on premise hardware infrastructure versus getting instant cloud computing resources and scaling them over time is irrelevant for most startups.

Similarly, software containers, made famous by Docker, are revolutionizing the way we package, deploy and run software.

One thing that hasn’t evolved enough since the industrial era is how organizations are built and run.

What I’d like to share in this post is a perspective on how to think about building organizations by making the analogy with software containers and how they changed the way we create and deploy applications.

Many years ago, I was working as Product Manager for Ericsson building a customized mobile banking, brokerage and payment solution for one of our customers.

The resulting product was a commercial flop, but that’s a story for another day. The most interesting aspect of that experience was what I learned about building and working with hybrid distributed teams and how it completely changed the way I look at organizations.

The project involved teams from units in Ericsson Netherlands, Sweden, and the UK. Besides, there were people from 3 external partner companies spread out in Canada, India, and Portugal working on different parts of the product.

In the beginning, there was much more commercial and legal work involved to setup all the contracts and scope agreements with the external partners than with the internal Ericsson units.

I started the journey by having a clear distinction in my mind thinking we’re building part of the product in-house, in the various Ericsson offices, and we’re outsourcing other pieces to external partners.

In the early phase, it was painful, frustrating and slow. Some people didn’t get along, some had to be replaced, and one of the external partner companies was sold and dismantled.

It took tremendous efforts to navigate the bumps and get all the external teams onboard with our internal product development methodology and ways of working.

However, as people got to know each other better and got used to working in common ways, the lines between the external teams and the internal ones became blurry, and over time those lines completely disappeared on the day to day work activities.

Traditionally, in many companies, any team or function that is not part of the in-house organization is considered an outsourced activity.

What I realized is that the assumed separation goes away when the external “outsourced” teams get to know the internal ones well enough personally and start to operate through common communication routines, problem-solving sessions, transparent information sharing and progress reviews built on the top of a well-structured baseline with clear split of responsibilities.

So in a way, the fact that the external teams belong to different legal organizations, are located in various countries, are subject to different labor laws, have different employment contracts, and different vacation policies doesn’t matter much.

What is important are the actual people that belong to those external teams and their ability to learn how to interact and commonly work with each other. Once they reach a certain level of close cooperation, adhere to shared routines and trust each other, they don’t seem anymore as “internal” and “external” but become part of one single whole.

“That single whole is what should become the new perception of an organization.”

So what does all of this have to do with software containers?

For those not familiar with the concept, here is an excellent introduction by Preethi Kasireddy

The advantage is that each piece of software inside a container can run in its isolated environment with its own internal specific attributes but at the same time, all pieces can have the ability to interact and communicate with each other.

More and more, modern software products are designed as a collection of small containers that each accomplishes one function and interacts with each other. When these different small containers are orchestrated by a common entity, they become part of one single whole which is the overall application. (also referred to as microservices architecture)

Put in a simplistic way, the most important aspects of each container that is part of an overall application are:

• The actual software running inside
• The way it interacts and communicates with the main application orchestration layer and with other containers
• Its status (running or not)

The least important parts are:

• The physical space where it’s running
• The internal file system hierarchy
• The internal process tree

Now, imagine if you have multiples teams spread out in various locations and working for different legal entities to which you are “outsourcing” some of the work. The work can be specific pieces of the product, design or anything else.

Every team belongs to different legal organizations with their own management hierarchy, internal work processes, office rules and employment contracts.

These external teams can be considered as small autonomous parts, similar to software containers, that interact with each other and are orchestrated by your overall host organization while abstracting away all their internal details.

In this case, the most important parts become:

• The actual people and talent inside these small independent teams
• The way they communicate and collaborate with the main internal host organization and other external teams
• Their status. Meaning whether they are in active working mode on your project, waiting mode or stopped mode

The least important aspects are:

• The physical location of the office space where they are located
• The legal entity they belong to along with its internal management hierarchy
• The internal work processes and office rules

The analogy between an organization based on distributed external teams and an application based on software containers can be visually represented by something similar to this.

For example, if a software application has a certain piece deployed on premise using physical servers and other parts are deployed on cloud servers provided by an external company, we won’t consider the first part as internal and the second one as external. They are both parts of the same whole which is the overall application.

The same way modern application architectures based on containers are improving how we design, build and deploy software, we need to push forward the way we build and run organizations.

We should move beyond the strong separations between internal, external, full-time, part-time, freelancer, contractor, subcontractor and start putting the importance on the actual people and improve how they work together instead of focusing on the underlying legal and physical structures where they belong.

However, there are challenges that come with such a model.

Throughout my experiences, I had both great outcomes and disastrous occurrences.

1. Not everyone is yet comfortable with remote and distributed work

Whether it’s one person or a team working remotely and regardless of their legal relationship with your company, the most important aspect is that people are comfortable and ideally prefer that kind of setup. If not, it would be tough to overcome the other challenges. So it is crucial to take that into account when you are initially assembling the team by openly asking each person how they feel about it.

2. Time zone differences can be challenging

In some cases, you may have groups in different continents with 9 to 11 hours time differences. This is always challenging when you need to setup video calls with everyone at the same time. The time slots that fit the regular workday of both are limited.

But at the same time, it can be a blessing. I had cases where I gave comments to a remote team late at night, then went to sleep. When I woke up in the morning and found the updated version of the product with all the modifications included, it felt like magic!

3. Lack of informal human interactions outside work

This one is tough. These days we have various video conferencing, collaboration tools and even remote presence robots such as Beam to bring people closer. In the coming years, we may also get some good VR solutions for that.

Nevertheless, nothing can yet replace direct interactions and the level of human connections achieved by spending time together and bonding.

The best way to overcome this is to arrange for all teams to meet, ideally, in the beginning of every major project and at least once every year in the same place. As the size of the overall organization gets bigger, it will get harder but the benefits are significant.

So isn’t it easier to simply stick to the traditional monolithic organization?

It seems easier because the management and organizational practices to build and run a traditional organization based only on full-time employees, in the same location, have been around since the industrial era. When it comes to hiring, structuring the hierarchy of teams, compensation, performance management, communication, culture, … Most companies are built on practices that have been used for many decades. Some have their own twist and specific internal ways but overall, it’s derived from the same base model.

In contrast, we still don’t have a widely agreed on set of best practices to build and run a modern organization based on a distributed mix of full-time employees in a central location, full-time employees in remote locations and freelancers/contractors from other external companies. This is mostly done ad-hoc and is still work in progress.

What we do have though is plenty of modern collaboration and communication tools such as Slack, Trello, Asana, Dropbox, Google Apps, Github, Zoom, … that bring people closer, make work more efficient and provide a more transparent information sharing.

So the technologies are already available and will keep getting better. The last piece to nail is a well tested set of practices, around those tools and around people, that can be easily adopted by every company to bring all those distributed hybrid teams together and have them operate as a well oiled single whole organization.

One company that seems to have, at least partly, cracked the formula is GitLab. They have 160 employees spreadout all over the world.

It’s worth watching the full interview with their CEO Sid Sijbrandij and Ali Rowghani from YC.

According to Sid, they didn’t plan to build a distributed organization from the beginning; it happened naturally:

“After a few days, they just started working from home”

They documented every aspect of their ways of working in a handbook publicly available.

Another great example is InVision. One of their engineers describes how it’s done in this post called Making remote working work.

The benefits of building such an organization can be huge.

1. Access to talent that you would otherwise not get

Whether you’re a new startup or an established company, you’ll be missing out if you only consider available talent in your location. Especially if you are in a place where hiring is extremely competitive or the pipeline of people with skills you need is limited.

By tapping into a global pool, you will not only get potential people with great skills but you’ll also get more diversity into your organization by bringing different international perspectives.

2. Efficiency & flexibility

As stated previously, time zones can be challenging, but you can also use them to your advantage to make your work flow more efficient.

Another aspect is about activities that are not required full time 12 months per year. For example, if you’re a startup building a hardware product. In certain phases of product development, you will need top industrial design, and mechanical engineering talent. At the peak, that part of the team will be needed full time but beyond certain milestones, there won’t be much activities around those functions. If the team was on a full time employment contract, it would have a negative impact both on the company and on the team members. Indeed, the best people will quickly get demotivated if they don’t have challenging work to do and will quit if they don’t have enough load.

So having a project based approach with external teams that are assigned for a specific scope and specific period of time will work best for both parties.

Lastly, there are also cost efficiencies that you can achieve by saving on office space and by tapping into international markets with lower costs of living.

3. Variety of projects makes people more creative and keeps them excited

Some of the best people don’t like to work on the same product/project for 2–3 years.

I once hired a freelancer for a specific project activity initialy for 3 months. At the end, I was so happy with his work that I offered him a full time employment. I was stunned when he declined the offer.

His reason was that our project was exciting but he could not see himself working on the same kind of product all the time. He wanted more variety and was still curious to learn new things by getting involved with different companies. He was happy to come back for another assignement with us if it involved something new.

This may seem as a constraint at first but it’s actually of great benefit. Having people onboard with a broader exposure to other industries and type of products will bring to your organization new creative ideas. You would otherwise not get those insights from somebody that had been inside your team working on the same product for many years.

Even with the challenges, the benefits of designing your organization as a collection of hybrid teams regardless of their location and legal relationship with your company are well worth pursuing.

This is where work is headed and the earlier you start experimenting with the model, the easier it will be to fully implement it as your organization grows.