What’s a tech choice?
As engineers, we often make choices and decisions about things like ‘Which framework to use?’, ‘What datastore is best for this use case?’ and ‘What architectural pattern should I apply here?‘. These are all examples of tech choices, and for me, tech choices are everything that supports our tech journey.
Why are tech choices important?
As I mentioned before, engineers make many decisions about following one or the other path on the journey. There might be multiple paths that will lead to the same place, some might have pitfalls, and others might accelerate you in the wrong direction.
It’s important to make decisions, as the act of not making a choice also has a cost attached to it. If we stop making choices or making decisions we risk slowing down or getting stuck, while others overtake us. Always keep moving forward. In my view, it’s better to make a decision to do something and then redo it later, rather than postponing the decision and risk never taking it, and being left in the dust.
Who should make the choice?
As I’ve transitioned into a new role, I find myself making decisions about different choices than I would before. A lot of the decisions I dealt with as a developer was mostly about very technical choices, such as ‘which pattern to apply’ or ‘which framework or tools fit this problem’. These choices seem harder for me to have a qualified opinion about, as I’ve moved further away from hands-on work, and now I find my mind is occupied with a different set of choices and decisions.
Therefore choices must be made on the right level. One of the pitfalls I’ve seen is that ‘managers’ try to control which framework, programming language, or design pattern a team should use for a given project when the manager is only there 10% of the time. This can lead to what I would call ‘forced choices’ or micromanagement. The manager in this case might believe that if he/she is not there to make the decision, then the team will go haywire and choose something completely insane. Most teams will try to make good choices, and they are, in most cases, more than capable of taking the company’s best interest into account.
As a manager, I find that it’s important to trust and allow the teams to make the choices they feel good about, and they trust me enough to pull in my opinion when they feel it’s needed.
Tech trends
Tech moves fast, and especially when one stops doing the hands-on work, it’s easy to get out of touch with what is trending, and become stuck in the choices of the past.
The choices of the past feel safe. We have already seen them working and they have gotten us to where we are today, but if we don’t renew ourselves, we eventually get slower and slower while everybody else overtakes us.
So how does one keep up with the trends? What are the cool kids looking at now? And how do you evaluate which trends have the potential to survive, and which ones never gain the tracking to become a real player in the field?
In my case, the answer to most of these questions is the same - tech radars.
Tech radar
Tech radar or technology radar was first used as a term by the company ThoughtWorks. It’s a company that helps other companies dealing with tech, and because of its unique position, they get to see a lot of what goes on in big and small technology companies. Based on this they created the Thoughworks technology radar.
The radar is a pretty simple concept.
It is a radar that is updated every half year, by an advisory board from within ThoughtWorks. It is split into four quadrants Techniques, Tools, Platforms, and Languages & Frameworks. Each quadrant has four rings, Adopt, Trial, Assess and Hold. Within each of the quadrants and rings, ‘blips’ are placed. A blip is a representation of a specific technique, tool, platform, etc. The closer the blip is to the middle, the more of a stable choice it is. If it’s in the hold category you should be cautious using it. If a blip is in two consecutive editions of the tech radar, then movement is also indicated, so one can see if it moves closer or further away from the middle, or if it is a new addition.
The reason I really like this tech radar is that each blip is well described. This makes it really easy to get a good overview, but also to reject the ones which would not fit into one’s own organization.
There are other companies doing technology radars too, which are also worth a look:
Transparency into your organization’s tech choices
Technology radars are not just for other companies. They can also be used in your own organization to assess the choices already made or to assess possibilities or opportunities which could accelerate you.
Thoughtworks allow you to build your own by just supplying the data. This can be a great opportunity internally in your company to help you coordinate experiments across teams, and gain the knowledge when one team finds a new and promising technique.
Final thoughts
I have really wanted to do a technology radar for a long time, and my organization is warming up to the idea. Not only can it help internal communication about which technologies we use, but it can also help give candidates a good look into where the company wants to move if it’s made public. We are starting to do team-specific tech radars first, and will then move into company-wide tech radars, and then hopefully in the not-so-distant future make it public.
Thanks for reading along.