I'm curious about how different companies handle the approval and grading of tools that are built internally by their engineers. We often see custom scripts and applications being shared informally, which sometimes become the standard way of doing things. Does your organization have a formal process for vetting these tools before they can be used by everyone? What kind of testing and approval systems are in place? Do you rely on trust, or have you ever had to ban certain tools? Also, do you have terms or classifications for different levels of approval?
4 Answers
From my perspective, being part of a large corporation means we have a lot of controls when it comes to tools. For simple scripts, you have a lot of freedom, but once you start talking about web tools with user access, the approval process gets pretty intense. There are multiple layers of teams involved just to keep everything compliant.
In my tech-heavy company, tools usually sprout organically from an engineer's need to automate a task. If a tool gains enough traction, it goes through a review process involving senior engineers and leaders to ensure it meets all necessary requirements. Fortunately, it’s generally acceptable to use one-off scripts without formal approval, as long as I keep it within my team’s scope.
That sounds a lot like what we do! We don’t have an officially documented process for moving an app along, but once management notices something taking off, they assign an owner to refine it and ensure it works properly. Do you have any naming conventions for the tools based on their risk levels or usage?
In my experience, it's all about having a manager who understands the tool's value. If your team sees the potential, they’ll likely rally behind it. But some people just want to stick to what they know, which can lead to resistance. That’s where management comes in—they can help encourage others to adopt better tools.
We keep it straightforward at our place. Changes are categorized as either standard (low risk) or review-required (medium/high risk). Standard changes get an automated ticket, while anything that affects production gets reviewed by a team lead. This system keeps everything organized without bogging us down with too much paperwork.
I can totally relate! The moment a tool is shared beyond just a single team, it feels like the requirements explode. We've had to pull the plug on several tools simply because they didn't meet corporate standards after getting too popular.