Picking tech

Something I have learned during brainstorm sessions, is to allow people to share whatever they want. Even if an idea doesn’t make complete sense. The initial session should be about putting all the cards on the table. It’s possible in subsequent sessions, when the goal is to cement and validate an approach, to give your opinion. Why it won’t work, or why it could work if only X. A manager should rarely force an idea upon a team, unless they have non-trivial experience with whatever they are pushing. It’s unlikely that a manager will suffer on a daily basis with whatever approach they have pushed for. It’s the engineers who will have to build, debug and maintain a solution - no the manager. The balance between choices is based on the following: 1) it fits the requirements, 2) it’s battle tested and 3) there are team members with experience.

The first two points are the most important. During brainstorm sessions, you should try to keep the team honest about what you are trying to solve. Often engineers get excited about X without it solving the problem at hand completely. Once a technology fits the problem, check if enough people use it and how easy it is to find documentation and solutions to common problems. An example could be choosing Dark Lang. Is it exciting? Sure looks so. Could it solve your particular problem? Likely yes. What’s the chance of getting blocked on the first couple of roadblocks? Very likely.