It is a case of letting the best people determine when a new tool will speed up a process and having the environment where they can take the time to write the tool.
Too often the environment is hostile to what might be a risky investigation. I've spent a week investigating a tool to potentially save four weeks. I failed, as I hadn't sufficiently understood the complexity of the problem. But ultimately that failure led to a better understanding. I changed the way we carried out the task, saving us a week anyway.
My project manager at the time thought that week was a total waste of time. (Thankfully he was later "let go" when 360 degrees of people who had contact were saying the same things). If I do that task again, I will have a go at v2 of the tool, and probably get it right.
Too many people think tools are a waste of developer time. It appears that the best tools where I've worked have been created in developer's free time, and then used widely by the team, almost to the shock of the management. Only then do the developers get a little work time to maintain or even improve them.
But yes, you can go the other way. In the largest organisation I have worked in, there was the "infra" team. Their job was to provide the environments, from source control to db instances (Oracle ones), test environments (multi VM set-ups), etc. However their removal from the actual development team resulted in tools and processes which took about as long as for us to do these things with our own tools... the same ones they'd taken to improve.
Too often the environment is hostile to what might be a risky investigation. I've spent a week investigating a tool to potentially save four weeks. I failed, as I hadn't sufficiently understood the complexity of the problem. But ultimately that failure led to a better understanding. I changed the way we carried out the task, saving us a week anyway.
My project manager at the time thought that week was a total waste of time. (Thankfully he was later "let go" when 360 degrees of people who had contact were saying the same things). If I do that task again, I will have a go at v2 of the tool, and probably get it right.
Too many people think tools are a waste of developer time. It appears that the best tools where I've worked have been created in developer's free time, and then used widely by the team, almost to the shock of the management. Only then do the developers get a little work time to maintain or even improve them.
But yes, you can go the other way. In the largest organisation I have worked in, there was the "infra" team. Their job was to provide the environments, from source control to db instances (Oracle ones), test environments (multi VM set-ups), etc. However their removal from the actual development team resulted in tools and processes which took about as long as for us to do these things with our own tools... the same ones they'd taken to improve.