Don’t Design Against Your Team

Each time we start working on a new project we need to answer the most popular question in IT: which technology should we pick? A few issues ago we wrote that We should be boring. So, if we want to use the most popular stack, the answer is simple: use PHP. Around 75% of the web pages use PHP (according to TechJury and W3Techs). If you are more into mobile, desktop or firmware development than web, you should be able to find similar reports like Software Developers Statistics 2024 by JetBrains, 2024 Stack Overflow Developer Survey or just look at GitHub repo stars and pick the most popular one. That sounds right, doesn’t it?

Before you laugh, read this paragraph again and replace PHP with React, Flutter, Kubernetes, or even AI. It looks too good not to apply it, am I right? Don't fall into that trap!

Let’s check how we can make an educated decision about technology in our team or even organisation.

Checking competences

PHP would be great if the developers in the company knew it well. A simple way to check competencies is by using a team skills matrix, a tool that allows us to map skill “points” to a team member. The simplest possible form of it looks like:

where technology is scored by points from 1 to 10. However, instead of a standard 1 to 10 scale, which monger be difficult to measure (am I 6 or 8?), consider using an experience-based scale such as:

• “hello world level”, “production experience” or if you wish “padawan”, “knight”, “master”

• Novice (“What is it?”), Practitioner (“I can do it”), Expert (“I can teach it”)

• Shu-Ha-Ri - A progression from following instructions (Shu) to independent practice (Ri), which is loved by scrum and well described on Martin Fowler blog

Which underneath might point back to “point scale” for easier calculations.

If you would like to read more about it, it is well described in the Experience report: Team Competence matrix – Agile Strides

No matter what option to score skill will you choose, all of them work well initially and later require calibration. The most import is to start, and start simple, then later you can evolve. Remember, “boring is good”.

The main benefit of skill matrix is: we have a strategic tool to assess and visualize knowledge, which tech leaders can use in three key areas:

• Internal and external training

• Work/project assignments

• Identification of gaps in competences (are we ok that we do not have kubernetes skills in the organization? Should we have more db experts on board? etc.)

Having data in table format we can use best possible way to display it. Simple matrix is fine in tabular format for small teams, however if we need to present data across organisation, department, product, or even across teams, data in table will stop being readable. Hence to scale it, use for instance a spider/radar chart (see below) to aggregate it at team, department or organization level.

This aggregated view can avoid future problems in choosing technology based on the team, while the rest of the organization doesn’t know it at all. Moreover, looking at aggregated data might help in organisations that can use matrix as reasoning to fire a person or put him into a performance review program. It supports a “blameless” way of thinking, and because of that, we can concentrate on organisation problems and strategies rather than pinpointing that someone lacks Java knowledge.

To sum up, while actions from a management perspective are relatively easy to initiate, they are much more challenging from a technical leader's perspective. But there is one point that is a low-hanging fruit. If you want success, start with the technologies that people know, instead of choosing something fancy.

A new buzzword on the horizon

From time to time, the company needs to extend its current technology stack. For instance, currently, almost everyone is attempting to integrate AI into their products. We can, of course, discuss if it makes sense to add AI everywhere or not, but as a staff+ engineer, we are hired to solve problems for business requirements.

When using a competency matrix for a new technology, the best-case scenario is having a few members with 'hello world level' or 'I did a PoC at home' experience. That’s why we need a new matrix:

Let’s dig into the columns. Weight defines how important this is for us. Be careful because it will have a big influence on the results as it is a multiplier.

Categories are more complex as there isn't a definitive list. The best option is to brainstorm and try to find what’s important in a particular case. It could be:

• Tech stack aligned with current development skills - it will be easier for developers to use a well-known language or framework rather than a new one.. For example we can consider something in PHP instead of a Python tool.

• DX, DevOps, etc. - if we are already using something similar it will be easy to reuse it. For example if we can pack it in Docker the hosting part can be similar to the existing solutions.

• Assumed willingness to adapt to tech stack by current developers - it is difficult to explain without an example, so imagine that you will propose Java developers to write solutions in dotnet. It can be quite hard, while changing from JavaScript to TypeScript doesn’t seem very problematic.

• Perceived employees market - not an easy category, because it is difficult to check. Still we can try to use a survey by HR, look on the job boards, etc.

• Community & knowledge base - if we choose a niche technology, finding answers to our questions can be difficult. With well-known technologies, it should be much easier.

• Stability - how regular new versions appear on the market, who is responsible for development, etc. While it's somewhat speculative, it's more likely that Google will continue supporting their framework compared to a single developer maintaining a GitHub repository.

• And more depending on the product including for example: compliance, LTS, costs, testing, …

Of course the result doesn’t give us a perfect path, but instead of a guess we can try to log the arguments why we choose X over Y. In the future, when the selected technology doesn’t work, we could take a step back and revise previous reasoning. Exactly the same we do in architecture decision records. Nothing is set in stone forever.

Choosing technology based on context, not trends

We should promote the idea of being "boring" by choosing technology that is best suited to our specific context. This means prioritizing practicality and reliability over the newest buzzwords. However, it's important to discuss how we can achieve this. Some might think that simply choosing the most popular stack is the answer, but that's not always the case. I hope that the tools and strategies discussed above will help guide you in making informed, context-appropriate technology choices.