Our clients often try to push us to hire freelancers and remote developers to expand the team. Sometimes we agree, but more often – we actively resist the suggestion 🙂 This article will help us to understand various schemes of remote development and determine which schemes are efficient for different types of projects.
The first step is to define the terms. If we talk about physical location of employees and degree of their involvement in a project, there are two basic dichotomies: Contract vs Staff Employee and Office vs Remote Work.
What is the difference between remote work and freelancing? In case of remote workers, an employee is hired for permanent job and becomes a full-fledged employee. Both parties are responsible for their actions and decisions. A freelancer is hired for a specific task or project and can simultaneously engage with multiple projects. The shades of the red the following diagram reflect the degree of employee’s engagement in the project. This is about motivation, responsibility and zeal.
“Remote” by 37signals
We have analyzed the famous book “Remote” about the experience of the company 37signals (now Basecamp). We are also aware (foreseeing legitimate question) of how Linux and other large and well-known open-source system have been developed. By the way, our employees are involved in some of those projects. We also know that the capitalization of the company Automattic, which developed and operates the WordPress platform, exceeded $1 billion. As for the experience of 37signals, the book makes an ambiguous impression. In our opinion it is primarily a PR tool. It seems that the philosophy of remote work in 37signals is more targeted towards employee satisfaction than to direct economic benefits (for example, emphasizes that it’s not about saving on salaries), although of course it is related. It’s very important when company cares about employee satisfaction, but we are not confident that remote work brings more satisfaction to employees, often it’s quite opposite. Also if we talk about our client’s goals, they are usually more pragmatic: to save costs, rather then bring satisfaction to our people. Yes, the organization of total remote development process in the company is possible, BUT only by titanic efforts of company’s management, its HR department, and other services. Only a large company can afford that. For a small company, overhead of organizing the remote development process, including training, team building, regular “gatherings”, maintaining the corporate culture will far exceed the savings achieved.
As for the open-source projects, completely different attitude to planning, deadlines and development discipline is practiced there, in comparison with commercial projects. But that is completely different story.
IT – Business: building complexity
Since the IT department does not exist by itself, and generally serves the needs of a business, let’s analyze popular models of business and IT collaboration. We are going to start from a very simple monolithic scheme and proceed to a more structured organizations.
1.Scheme One: monolithic office. It’s a classic scheme where developers work full-time in the office of a company. Example: securities company and its staff developers, serving the internal needs of the company. IT-department is often found on the same floor as that of traders and sales-managers. Accordingly, communication between departments takes place at all levels, including personal, over a beer at a nearby bar.
2. The first step of structuring: internal outsourcing. In this case the company developers are separated physically from the main office, for instance, IT department is located in another country. Example: the main office of the financial services company is based in London, and the IT-department is based in Moscow. IT department staff still works full-time in the company, but in most cases it’s not just the language barrier, but a narrower window of communication due to the time difference. To avoid problems with communication the processes of interaction between IT and business should be very clear.
These two models work well for companies with technical background, which have sufficient expertise to organize the IT department.
3. Classical outsourcing. In this case, the business contracts the development from other companies, perhaps in another city or another country. Example: financial company based in London contracts an IT-company in India for development of a banking application.
There is no major difference between the internal and external outsourcing in the context of our discussion here. These are quite workable schemes that can effectively solve complex technological problems.
The thing is, the work of technical teams (development, testing, technical support) is supported on the organizational level. Each developer has a manager, which can be accessed in case of problems, the technological culture and development discipline are maintained. Also there is a set of development methodologies used, there is an architectural process. There is a constant learning of new technologies, training, exchange of technological knowledge: both controlled, and – more importantly – spontaneous.
4. Finally, we approaching Pure freelance. In this case, the temporarily contracted developers are working remotely. It should be mentioned that although financially the freelancing scheme looks attractive, it has serious drawbacks. Freelancers work differently than regular employees. Any work they consider as a one-time assignment. Freelancers primarily optimize their time and pay less attention to quality. Of course, there are Upwork-type platforms, which provides an potential employer with member ratings and long-term contracts, but even in this case there is a risk, for instance, when freelance specialist suddenly disappears.
Here is a list of the main reasons for hiring external specialists, including freelancers:
- Reducing of the cost
- Need for rapid scaling of the project when it is impossible to expand staff
- To find person for a specific task, some narrow specialist
Compact team
Let’s now limit our scope from freelancers of all stripes, to freelance developers specifically. Interaction with them can be arranged in many different ways. Developers can be managed by a PM from business department, or they can complement the internal IT staff and be managed by the IT department, and in some cases, even project managers themselves can work remotely. It’s hard to imagine, but it happens sometimes!
In our experience none of these schemes works. The main problem is that the core team or – in military terms – a combat unit, working on the same project – is scattered and not located compactly. This has a negative impact on everything: product quality, developers motivation, the ultimate performance. It is important that we are talking about a team of experts of the same profile (like Java developers, testers, UX specialists) working on the same project, especially complex one. When a team is a heterogeneous (one developer – one designer – one analyst – one tester), it’s okay to work in distributed manner without significant loss of efficiency.
What is also important, unlike, say, sales-managers, designers, and other people of business or art backgrounds, developers and IT folks in general are often introverts. Among them are many so-called geeks or nerds. Most talented developers often have difficulties in communication. When such a silent person is working alone on a small project, it’s okay. But when it comes to team activities, you must use all the tools and provoke communication with team members. We have repeatedly observed, how “relocation” of the project participants into one room considerably increased the team’s performance. Even if before they were working in nearby rooms.
Motivation
In our experience, the average duration of freelancers’ work on a project is about six months. Even if we are determined to keep the guy or girl, they somehow disappear, often without a trace. Remote staff employees survive longer, on the average for year or two. Then they either change employer, or even radically change their business.
As for the core of our staff, many of us work together for 10-12 years. And to a large extent this is due precisely to the fact that people are motivated to work in the team. And every day to meet their colleagues in person, see smart faces, and work together to solve complex problems. As well as to tease each other, to argue as crazy, to make kebabs and to occasionally “relieve stress” the most popular way.
It is a fairly well-known fact that smart people like to spend time in the company of other smart people. Actually that is the main motivator for working in the office.
By the way, where do programmers come from?
It was believed before that programmers were found in piles of punch-cards and computer printouts. And now, in the paperless era?
College or university? No. It is clear that education is good, especially good education. But at the universities, at least in Russia – people are not taught programming, at best they learn C or C++. Although they are often given much more – thinking skills to solve complex problems, especially when it comes to mathematics majors.
The only way to become a good developer – is to take part in several large and complex projects. And such projects are only granted to established companies operating in the traditional paradigm. So we came up to the fact that in order to become a good developer, one need to work at least a few years in a well-organized and disciplined team. To walk through the projects, successes, failures, trainings, drills and all the difficulties of growth and maturation. Yes, among freelancers there are good programmers, but they are all, without exception, have passed through traditional working school.
There is another interesting point related to motivation. Somehow, it is believed that the staff is eager to work remotely. And it is believed that the ability to work from anywhere you like: home, seaside, coworking in an exotic part of the world – is a huge advantage when choosing an employer. However, by looking at our limited experience, as well as the results of more serious research, it turns out to be not so simple. But this is the subject of a separate discussion.
Size is important
A case in point is the size of the project. There are two main criteria by which we determine the suitability of one or another scheme of work on the project:
- The complexity of the project
- The significance of the project for business (deadlines, risks, responsibilities, etc.)
What is a complex project? It’s kind of a special operation. Accurate planning, tight deadlines, high risks, changing external conditions and high uncertainty. As a result – a battle group frees hostages or neutralize gunmen, development team releases complex project to production almost on time. On such project you need a good planning and coherence of the whole team.
And yes, small systems can be developed by freelancers. Especially if the work requires not more than one specialist in each field: one analyst, one developer, one designer, etc. Such a project can be well coordinated by a single project-manager who can also operate remotely.
Here is another situation. Even if it’s a huge project, but there is no strict deadlines and budget, development can be carried out on the enthusiasm of open-source developers spread around the world. Please note – they are NOT freelancers. They are, first and foremost – enthusiasts, i.e. people who have the highest level of non-financial motivation, as opposed to freelancers. Secondly, they are highly qualified specialists, many of whom work full-time in large commercial companies, and devote their free time to open-source. Accordingly, the popular belief that “Linux was written by freelancers” is not quite true.
However, when it comes to medium and especially large commercial systems, the situation is changing. There is a need for team. Even if it is a team of just two people, it is fundamentally different from standalone professional. Teamwork on a complex project can be compared to a military operation to free hostages. Only teamwork, discipline + initiative, the exchange of information and skills, the uninterrupted communication, constant training is the key to success.
Complex and important (deadlines, business risks) projects could not be carried out by freelancing scheme. The sufficient level of communication and responsibility can only be achieved by a compact cohesive team.
So how do we save?
There ain’t such thing as a free lunch, but there are ways to optimize costs. Naturally, they usually involve overhead, nevertheless provide fair compromise between quality and efficiency on the one hand and the development cost – on the other.
The structure of any project is not monolithic: each project consists of several components. For example, on our typical projects development team contains an analyst, a graphical designer, a usability expert, back-end developers, sometimes DBA, front-end developers, mobile applications developers, testers, etc. Then part of the work which is not related to the core of the project (e.g. business analysis, design, usability) can be delegated to outside specialists: companies or proven freelancers.
SnapChat of help?
We often hear that in the presence of modern communication tools, such as video conferencing, chat, corporate knowledge base (wiki), bug trackers, etc. there is no much difference whether the employees are sitting in the same room or spread around in different parts of the Earth. Yes it’s now impossible even to imagine working on project, whether local or distributed, which did not use all of these tools. Actually, right now all urban citizens – friends, relatives, acquaintances – are constantly “in touch” whether in chat rooms, instant messengers or social networks, regardless of work relationships. Can it substitute face-to-face? When working under the same roof people communication is much more intimate and less formal. They exchange information in a broad stream. Spontaneous discussions are often popping-up, or even violent disputes at office, birthday party or in the nearest pub on Friday night. Just by being around people motivate each other to work productively.
The bottom line …
We’ve discussed several scenarios of using remote specialists in the development of software systems. The feasibility and effectiveness of their work depends on the organization and objectives of the project, its size and complexity.
Experience of well-known and successful companies, such as Basecamp, Automattic and others, has shown that a full-scale distant work on large projects is possible, but its efficient conduct requires focused efforts and huge organizational expenses hardly justified for medium and small companies.
Standalone professionals can be used on remote basis, not a problem. When more than standalone professionals are required for project implementation, when it requires team of specialists, the remote work becomes inefficient. But still the team in it’s entirety can be “remoted”. This applies not only to hard-core technical staff, but also to designers and even sales-managers.
For example, if the project only needs one designer, she can participate remotely, but as soon as the amount of work on the project grows and more than one designer is required, it is more efficient to hire them, and proceed with all the “boring” organizational actions such as appoint one of them as the manager or lead. Or another option would be to contract a company specialized in Web-design.
At the end if we turn to the military analogy again, that’s how the structure of the project combat team may look. Yes, combat units could be distributed, but each of the units should be densely located, so that each fighter felt shoulder of each other.
