While there are obvious things to consider on this journey, here are three not-so-obvious questions to ask yourself when assessing new technology:
What are My Own Motivations for Choosing This New Technology?
If you find yourself looking for reasons to fit a new technology into a project, take caution that your motives are well-intentioned. You shouldn’t twist yourself into mental pretzels finding a spot to work with a new piece of technology. This opportunity can be a great resume-builder (of course), but not at the detriment of the organization you are assisting. Rather, you want to find opportunities where your own interest matches that of the organization. This will lead to all parties being enthusiastic about what gets delivered, a truly win-win situation.
And now that we’ve focused internally, the next question is focused more outward.
What are the Core Competencies of the Team as it Exists Today Implementing the Software?
This one can be tricky. You should try to choose technologies similar to the languages and tooling already being used by a team. This isn’t to say branching out to new opportunities should be avoided. Quite the contrary. You want to branch out strategically from a team’s core skills as to not overload them.
For example, if a team is familiar writing C# and needs to choose a front-end framework, using Angular with Typescript will be approachable given the support of Visual Studio Code, backing of Microsoft, and some syntax similarities between C# and Typescript.
It’s also important to pick your battles when introducing new technology. If you choose too many new things at once, you run the risk of drowning a team under a new learning curve: new tooling, new language with a new syntax, possibly a new IDE, and on and on and on. Instead of the team solving tough business problems with something new, time will be spent frustrated with “new.” The team will be more prone to give up reverting back to something more comfortable and even less likely to try new things moving forward.
Now we’ve checked our own intentions and made sure the team can handle the challenge. Let’s broaden our focus a bit.
How Large is the Talent Pool on the Market Today for a Given Technology?
You should never be under the pretense that the team responsible for the initial implementation of software will be the same team twelve months from now. Life happens and as such people move on to new opportunities over time. This means the team will have to backfill positions with new team members.
The goal here is to leave the organization able to fill positions easily from a large talent pool. Replacements shouldn’t be difficult to find. Some quick market research will bring out what a given talent pool around certain pieces of technology look like. Even open-source software can have hidden costs in this regard. Picking software with a wide talent pool will help the employer choose the right person for their company. They won’t be held captive to a codebase and customers that need attention quickly. It will lead to a happier organization in the long run.
As a frame of reference, I usually ask these questions near the end of my assessments to bring my recommendations into alignment with what feels like sometimes-competing interests. I’ve found them to be very relevant and revealing. I’ve even changed recommendations after exploring the answers to these questions. Hopefully, you will find these questions as insightful as I have.
