Internal tooling feedback loop

The best measure so far that I found if the particular internal tool is "good" and useful is by looking at how long it takes for a team to start to fight it (ex. create workarounds or avoid using it), or how long does a tool survive inside the company without original author effort to enforce using it.

What if there would be an easier way to build better internal tooling?

Shorter feedback loop

As we tend to forget Agile approach is all about having a short feedback loop and iteration cycle, and in many places this work really well. With internal tooling, it also solves another culprit - having no visibility or impact on tool roadmap (if there is even one) as well as often dealing with docs/tools that were abandoned by their authors and there is no clear way how and if you can contribute to them.

Document templets (Miro boards, spreadsheets, or just word docs) often have zero feedback cycle and improvement on them. Those documents are often created by one person, maybe they tested it on one team and then shared it inside the organization to utilize (ex. postmortem template, retrospective board etc.). Very rarely did I see those documents being actively improved once they are adopted as "standard" in a company.

Solution? Create a feedback loop, the shorter the better. So people using this template or tool have a clear way to propose a change or even better - they can vote for tool backlog/propositions.  How? It is up to you. In the case of internal tools as a website or app - make sure there is a link in a footer to the repository and people can submit merge requests, for a document template - make sure the template is non-editable but open to suggestions. A good idea is to have a feedback form, even the easiest one. It is a very easy way to notice main pain points for example our docs or templates.

Keep reviewing your team tooling

Setup a timeslot so every quarter you will do a retrospective with your team on internal tooling that is used by you, notice missing bits as well write down good/bad things with existing tools. Consider supporting people/teams who are responsible for your most valuable tools and reaching out to them offering you help or feedback.

Consider doing a review of available tools by starting with a clean sheet of paper - "if we were starting from the ground up - what tools we would create for ourselves?"

Reach out

If you or your team is creating some internal tools or services... do reach out to people in your company who are using it or you think they should (why not they are not using it?).

Having direct feedback on your work would allow you to better prioritize the backlog, receive some help - "we can help you build this", as well notice some issues that went under your radar, for example - that someone found a better existing solution or needs has changed?

Peer review

This is obvious for software products, but how many times have you asked someone to review documentation that you prepared? Was a document template peer-reviewed by someone else? We tend to focus on peer-review of code and ignore it in other aspects, embrace it (and its feedback)!

Internal tooling is a product

Many companies think internal services or tools (ex. logs browser, monitoring, status page...) are internal software and only this, ignoring that we should treat them like products. With a purpose and users. If you are building such tools - take a more Product Owner approach to things that you are solving and plan according to your colleague's needs and not your own hunch.

Consider beta channel

This better works with publicly available software but might work in bigger companies with more stable internal tooling. Create a beta or snapshot build with features just for testing and gathering initial feedback from a smaller group of colleagues - if they do not find that useful you can remove the POC feature and save yourself o lot of finishing work. Also, people using beta products are more willing to share feedback and do not get so frustrated with bugs.

Summary

If you build it - own it, or even better empower others to improve your work. Make sure that proposing a change is as low friction as possible to allow others to contribute. This is often a challenge with internal tools that are owned by an unknown closed team with some specific domain knowledge and their own backlog - which is also not transparent to others.

If you have created a document template or documentation for others, allow others to suggest improvements, create a feedback form, or even better - keep reviewing it from time to time and reach out to people who are utilizing it.