Staying Fresh: How teams can adopt tools and technologies.
The goal of this post is to describe a technology evaluation process which my teams use to try quickly, adopt slowly, unwind strategically.
Technologists are tool builders and tool users. The evaluation, selection, and mastery of tools is a core responsibility in our profession. Selecting the right programming language, application framework or development methodology is one of the most important and potentially long-lasting decisions an engineering team can make, bar none.
For the product, choosing the right tool for the job is essential. The choice can have long term implications for the product’s success or failure. These foundational decisions are some of the most long lived and consequential choices for companies to make. In many cases, they outlast the people that made them. Imagine you bootstrap your new product on a flavor of the month application framework. Then within months it quickly falls out of vogue and is eventually abandoned by even its own maintainers. Now you find yourself staring at the prospect of a monster refactor or to be buried under a mountain of technical debt that you might hopefully someday climb out from under. This can be fatal for many fledgling products.
For the team, tools shape the composition and capabilities of what future members must know before they can join. If you pick an emerging language it may be hard to find enough engineers to fill your vacancies, and overall velocity may lag. The opposite is also true; if you base your product on a legacy framework you may find that many of the best engineering minds have moved on to greener pastures, leaving you with fewer good choices for teammates and a stagnant ecosystem and community.
For the individual, tools shape your growth opportunities. Often the emerging technologies are were developers first brush up against the next wave of computing concepts, which may become essential information later. Many knowledge workers are polyglots by nature, collecting programming languages as a means of getting smarter but also improving their marketability in the employment landscape. The desire to stay relevant can sometimes cause engineers to choose a tool that’s right for their career but wrong for the team or product. I have inherited more than one team who was responsible for babysitting some application written in some esoteric language by a person who is no longer with the company.
As technical leaders it’s our job to keep all these competing priorities in context with one another. We must help the team choose, when they should stay the course with an existing technology, when it’s time to unwind from a previous tool choice and when it’s important to move onto something new. Importantly, we should not do this alone.
Many companies have technology steering committees or governing councils that meet periodically to evaluate the internal and external technology landscape. Some companies like Thoughtworks externalize this process, publishing the results periodically as a means of influencing others and I am sure as a subtle form of customer acquisition. Thoughtworks’ “Tech Radar” divides their recommendations into one of four categories:
Adopt – They feel strongly that the industry should be adopting these items. They also use them in their own client work.
Trial – Choices in this group are promising and worth pursing in projects where risk can be managed. It may be strategically important for companies to understand how these tools work and to be encourage their teams to use them.
Assess – These technologies and ideas are interesting enough to merit exploration and thoughtful consideration by the team. They may be too immature to dedicate substantial resources into learning them, but it is important to at least develop a perspective on how they might affect your company or team.
Hold – These technologies and ideas have either fallen out of favor or are so new that there is not enough data to form an opinion on them yet.
I would add unwind as fifth category to this list, which is specific to internal teams.
Unwind – Items in this group have run their useful course and must be unwound from the companies stack in a thoughtful and deliberate manner. They could be obsolete, or insecure tools or technologies, or simply choices the team no longer want to maintain.
The advantages of projects like Thoughtworks’ Technology Radar is at least the following:
- Provide a regular cadence, format, and venue to evaluate tools, methodologies and ideas.
- Give technology leaders within the organization a chance to meet and cross-pollinate on topics they care deeply about.
- Provide direction, and stability within the organization on how important technology decisions are made.
- Drive alignment between teams, and divisions within the organization.
- Provide a document to drive awareness within the larger organization of what the technology landscape is, and what the organization’s path through that terrain looks like.
- An archive of technical choices and evaluations which can be consulted overtime.