First steps to adopting tool standardization

Technology leaders who want to standardize the tools used in their company will certainly face opposition in the organization. Some people will say, “I have three engineering teams, it’s better to let them choose how they want to work.” There is no ideal set of tools because for certain tasks one is always more efficient than the other. 

The answer to this dilemma is that it’s worse for the company to be paralyzed waiting for a perfect system, because then a scenario arises where each engineering team has its own set of tools, and the whole company misses out on the benefits of the commonality provided by standardization. It’s preferable to have a well-defined set of tools, even if it’s not ideal for some of the teams or some areas.

For an established company thinking about standardizing its tools, the first step is to create an internal team dedicated to the engineering toolset. The role of this team is not directly linked to the company’s business goals, as its main objective is to make developers more productive. In practice, about 10% of the engineering team should be allocated to work on engineering tools. This group must be comprised of great professionals but hiring them can be challenging due to the scarcity of people with this profile in a market that places little value on behind-the-scenes work. The team needs to be senior and prestigious enough to enforce standardization at all levels.

Depending on the size of the company, the project to standardize the engineering toolset can become a long-term plan that demands heavy investment. It requires limiting the number of programming languages; choosing, building, and migrating tools and platforms; and reviewing the organization of the company’s repositories. All this must happen without paralyzing the production of new code and the company’s day-to-day activities.

It may be challenging to justify to the CFO of a company with 200 developers that they need to fund a new team of 20 people to define and manage the engineering tools. The simple and truthful justification that “collaboration will be much better in the future” probably won’t stick without well-thought-out arguments. 

A simple example of productivity could help convince those responsible for the money: with the right tools, developers can perform their tasks in much less time, especially when there are shared repositories, always synchronized. 

It’s preferable to have a well-defined set of tools, even if it’s not ideal for some of the teams or some areas.

The road to standardization

Imposing standards usually creates some resistance, so a tech leader needs to promote a cultural transformation to convince people of the importance of this initiative. The standardization of programming languages is a particularly sensitive point. The decision over which languages to adopt cannot be trivialized. Criteria must be used, such as:

• The popularity of the language within the company
• How easy it is to hire people who know that language well
• If good tools and libraries exist 

It is also advisable to look at the market and understand what is being done elsewhere, doing a careful examination of benchmarks, by talking to other players in the national and international market, and with technology suppliers such as Amazon and Microsoft, and then developing proofs of concept with prototypes, testing, and checking what works and what doesn’t. If some solution looks very efficient but no one in the market has adopted it, it is important to understand why. It might not be worth committing to a radically original path.

On the topic of programming languages, although language choices can be encapsulated by teams since the entire interface between systems is done through APIs, it is important to consider that for more exotic languages there may not be as varied a computing framework as is available for more popular languages. Perhaps, for example, there isn’t a suitable testing environment, and the company will need to create its own. A more popular language will have more tools to choose from, more open-source systems, more libraries, and so on.

There’s no need to take extreme stances. No company needs to have 60 languages, and there is no imperative to adopt a single language. An intermediate alternative is to have a language for each scenario: one for everything backend, one for frontend, one for data manipulation, and one for embedded software. Limiting the number of languages makes it easier to maintain standardization. 

If some solution looks very efficient but no one in the market has adopted it, it is important to understand why.

Culture change

No matter how rational the criteria used to standardize languages and tools, those affected tend to resent an imposition where there were no restrictions before. Standardization is necessarily imposing, and that’s why it is best if done as early as possible, because once the restrictions have been imposed, each new person who arrives at the company will no longer feel them like restrictions. They will just be the company standard. For those already in the company, resistance will only be eased if there is strong engineering leadership and a culture based on a growth mindset. 

Showing the team how much flexibility standardization allows helps in the effort to convince them. Tools enable people to work asynchronously and remotely, in different time zones, with a better quality of life. The company almost always wins points by swapping a meeting for asynchronous collaboration: engineers would rather do engineering work than attend meetings.

A technology company that encourages a platform mindset is one where communication is efficient and done whenever possible through tools. This toolset should be standardized enough for developers to feel agile and productive in taking good care of the code, and be open to collaboration, in an environment that values learning, fungibility between teams, and the construction of platforms that will lead to innovation.