No one can deny that the number of tools in the IT software application industry is overwhelming. For every discipline, there is a sheer amount of tools that promise to help your company execute its IT strategy. As the amount of tasks for a common DevOps team increases, the number of tools they use might also increase every year. Especially when those tools become part of the CI/CD pipeline, every developer has to deal with them in some manner. Adoption of new tools is needed as well as a good understanding of how to best use them. This creates extra cognitive load and mental energy to them and this might result in a decline in productivity. On top of that, developers might face more stress and frustration. Therefore it’s time to present Effective methods to avoid tool fatigue in your company.
Less is more
As with many things, more tools are not always better. Be very careful when deciding about adding another tool to the tool portfolio. It might be tempting to carry out a tool selection process to let the best tool address a specific problem. However, sometimes it’s better to take a step back and search for alternatives. These include the following.
Take a look at the future roadmap of your current tools. Announcements on Linkedin or on their corporate website might help here. Sometimes this information is not publicly available. In that case, talk to your vendor and ask for their roadmap. As this is sensitive information that might disclose their competitive advantage over competitors, it’s a good initiative that also shows your interest in a good partnership with them.
Explore plugins and extensions of your current tools. Perhaps the tools you already use provide this option (as well). There could be a plugin, extension, or another way to upgrade your existing tool to support the feature your need. An example would be to use the draw.io plugin in Confluence. Instead of legally enabling every DevOps expert to use this tool as a SaaS offering, direct them to use it in Confluence. Be sure to enable the export feature of it so they will be enabled to check the source into Git and add meaningful graphics to their designs. This saves using an extra service over which you don’t have full control. It is also incorporated into your existing tools which are already heavily being used.
Focus on cloud-native tools instead of standalone tools. Many cloud providers offer built-in services which are similar to standalone tools. Think of the container runtime solutions provided by Azure Defender or Container security scanning solutions like Clair which is build-in into the AWS container registry. Another example would be the Ingress controller capabilities of EKS. Under the hood, they might use a similar implementation like the nginx-ingress controller. A catch here is that you need to be absolutely sure that these cloud offerings conform to your requirements.
All of the above-mentioned tips help you to reduce the number of tools, so that’s a vital step in your assessment.
Be consistent and uniform
Consistency is king in every aspect of IT and especially in IT automation. Often, various enterprise-grade tools offer so many options to configure them, it can be very overwhelming. The more consistently you implement and configure those tools, the easier they are used by your developers. Think of the following ideas to create more consistency and use them in a more uniform way:
- One URL schema for all tools. Don’t use completely different URLs which make it very hard for users to remember them. Distinguish environments, for example by postfixing them with -d, -t, -a for development, testing, and acceptance environments.
- Try to leverage the same internal structure. Professional developers like naming conventions so they can automate things so they don’t have to deal with a lot of exceptions. It’s especially important to use a consistent naming schema for application (CIs) and their sub-components. The CI as mentioned in the Configuration Management DataBase (CMDB) should be leading and not being abbreviated. Avoid mixing up lowercase and UPPERCASE-based names, since also Windows and Linux treat them differently. Prevent changes to the internal structure and naming conventions as this might have an effect on the developers actually referencing them.
Use a single login type for all the tools. Everyone uses a password manager nowadays so strong passwords are not a problem. However, the different login methods to use your digital identity are still annoying. Sometimes you have to use your corporate email address as a username, another time only the first part of your mail address with or without the domain or another set of characters like a generated username.
It’s much more convenient to use SSO or at least the same login type for every tool such as LDAP-based authentication. This also reduces the likelihood of mistakes and support tickets to reset passwords or recurring questions from end-users.
End-users of your tools are not the experts who work with them every day. Therefore, it’s helpful if you supply them with the information they need to learn your tools to use them most effectively. Documentation plays an important role here. Structure your documentation and present it in a uniform way. For example, the way people can sign up for your tools, the way they can generate reports, or use the API. Use the same nesting of levels to differentiate main features as well as supportive features.
As seen, consistency really helps to avoid a lot of problems and improves the user experience for your set of tools.
API-driven workloads are not a new phenomenon anymore. If a tool does not have a decent API, there is no way to automate whatever is needed to implement, provision, configure and maintain it. This applies to the central IT4IT team as well as the end-users which automate their workflows to streamline their delivery process.
Since the APIs for every tool differ a lot due to their primary functions and the data fields they either accept or echo back to their users, there might be some functional overlap. Suppose you have the following similar features: user sign-up, register new CIs, assign project permissions, and create webhooks/notifications. Collect the heavily used features so you can build a so-called “developer portal application” in front of the tools which capture these requests and dispatch them to the right API for the tool in charge.
This solution greatly helps to ease the burden of having to consider so many (slightly) different ways to achieve the same goals. Remember that this only pays off if you have to take into account a great number of users which all place a large number of requests on numerous places.
Offer support in multiple ways
To avoid tool fatigue, it’s nice to offer support in multiple (interactive) ways. This goes beyond static information on a Confluence webpage. Think of the following ways to attract your audience and let them adopt and use your tools without much hassle.
- Offer templates and examples for common features which are similar to the same tech stacks or teams. Store them in source control and make the connection between applying them to the respective APIs to gain a proper adoption of them.
- Use “walk-in” sessions so that people can (digitally) walk-in into your “tool office” and ask specific questions on which you can give a solid answer immediately. This saves them a lot of time digging through extended documentation and other online sources.
- Present videos, podcasts, and other visual material like examples and use cases of other teams. This interactive material offers clear examples of how to use central tools.
- Build a Knowledge Base (KB) and a FAQ. This greatly helps to let people adopt your tools more easily and build up their knowledge. The best would be to add contributions of the community so you get feedback “from the field” which is extremely valuable to the credibility of whatever you offer to your consumers.
Multiple methods to offer support is extremely well received by end-users of tools and help “dullness” about how to use them. This greatly improves the adoption and effective usage throughout the entire organization.
IT tools are necessary to drive innovative applications in the DevOps era. They offer a lot of features for modern developers which. However, as the number of tasks increases, also the number of tools tends to grow (too much). This puts developers and other end-users under pressure. In this article, there are several methods to avoid tool fatigue in your company. Reduce the number of tools to seek for overlapping features, and be on the lookout for future features which might come available in your existing tools. Streamline (internal) structures and standards across your tools and make sure developers can utilize the same ways to log in to those tools. And last but not least, offer support in multiple ways so everyone gets familiar with effectively using them in the best possible way.