When reflecting on what insights and new perspective that I’ve gained the past years by going from being a Software Engineer to an Engineering Manager, the one topic that quickly comes up to my mind is about adopting new technologies to a company’s tech stack.

The developer side of me thinks either

• from curiosity and technical standpoint like “let’s use the best tool for the problem (which might be a new one)”
• or from a more out-come driven perspective “let’s use a tool we know and can develop and maintain the solution in” a.k.a impact-over-hype a.k.a. software is a means not a goal.

After several years working with software from the Manager side, I have an additional perspective on this that I’ll outline below.

The Problem

What I’ve seen happening several times in different teams is that an Engineer is very passionate about a programming language, framework or tool. This tech is new (as in more recent or modern) relative what is currently used in the organization. In agreement with the team and manager this new tech is adapted maybe as a PoC Proof of Concept - trying out an idea for feasibility to evaluate the practical usefulness or as an isolated service to try it out. This is a good thing! We engineers should always drive towards improving the technical solution that we can provide. What can go wrong is then what can follow after this first adaption.

Underlying problems:

• In businesses, PoCs Proof of Concept - trying out an idea for feasibility to evaluate the practical usefulness mostly becomes production software.
• In businesses, there are some moments where there is time for technical innovation and there are times when delivery is utter most urgent. This can mean that this new tech stays in one corner and does not get further adoption.
• As the settings was PoC-like, the knowledge tend to not be shared (properly) in the team and it’s mostly the driving Engineer that retains all practical knowledge of the component having the new tech.
• As in any business, people come and people goes and eventually the day comes when the Engineer in question moves on. This might event might even happen earlier than for other Engineers on the same team, as the drive for new tech might indicate that the Engineer is currently dissatisfied with the status quo tech stack (yes I’ve seen this happen more than once!).

This leads to the manager’s big problem:

• You and your team are now responsible for a component with a tech that the team does not know. If there is capacity for the team to learn this new tech, then all good. But in a business, this is in reality not a scenario to count on. Instead a new hire might be needed, that should meet the team’s normal expectation in terms of qualifications/experience but also must know the newly adapted tech as well. And this is the big issue, that it can be really hard to recruit someone who has this additional knowledge on top of the normal qualifications. Especially if the new tech is not in the same ecosystem as the “old tech”. Let’s say the company is heavily centered around Java or other JVM-languages, and the “new” tech is a Golang service, and your team is working on Big Data. It might not be as easy to find someone matching both those profiles!

Possible Solutions

The good thing with problems is that we can mostly solve them, in many ways :)

• The team can:
  • adapt a process where knowledge sharing is mandatory and integrated to the standard way of working.
  • only allow a PoC to become production software as a conscious and active decision (implies that active work is done to make the PoC meet the production requirements).
• The organization can:
  • involve tech leads (if applicable) or the CTO more actively in these decisions.
  • adopt what some companies call a Tech Radar. This is an artifact and a process for consciously evaluate new technology and decide how to adapt or not adopt them.

I’m especially found of the Tech Radar as it let’s the whole Engineering organization be a part of the decision process with the effect of the decisions being better, more well understood and followed in the end.

Closing

The perspective of it being hard to hire talents for a new tech to keep the teams staffed up was a perspective that I did not have when I was Engineer.

That said, it’s just one view of many. Let’s continue making the world better, which may or may not be by adapting technology X!