I see I need to add more specifics about my situation.
I work at a university developing research software (primarily - some is also external customer facing). My customers are internal customers, thus profitability and other business measures are not directly my concern.
The biggest issue I face with this is that my customers are non-technical people, so if I were to tell them that our infrastructure is now software defined and I have implemented analytics that will allow me to optimise the caching layer, they will most likely look at me with a puzzled expression and perhaps wonder what I'm actually doing since those things don't provide direct value to them.
The types of internal tools I am thinking of are things like; analytics, automated deployments, CI server etc.
One comment suggested I do a simple calculation like any other business decision. This is something I cannot for the life of me work out how to do. Internal tools will increase my efficiency in the future, so I guess at best I could estimate a payback time for some of these tools (like automation). Even so, how short a payback makes it worthwhile? For other tools, like analytics, how can this type of calculation be made?
Additionally, there are some things that are the "right way" to do things, such as software defined infrastructure vs managing it manually (which I currently do). Investing time in this won't have any immediate payback, but is nice to have in place in the case of a large failure when I need to recover quickly. These types of value calculations for me are not easy to make.
sourthyme, I like the idea of spending one day a week working on this stuff. Perhaps I need to have a conversation with my bosses/customers about this and try to explain to them the value that internal tooling will bring.
Thanks for the answers so far, please keep them coming.
In my opinion, you should not tell people who do not understand how analytics will improve your caching optimization that you are working on analytics. You should tell them you are working on improving the caching layer. If you sound confident that implementing analytics is required for this job to be done properly they will have to trust you in this, _you_ are the programmer.
You are correct in your assertion that when people ask you what you are doing, they want to know what value you are providing for them. So don't answer with technical details, you already know they're not interested in that :) Whenever a business stakeholder asks you what you are doing, trace back how what you are doing provides value for them and inform them of that.
Note that value does not have to be very direct. Caching makes your application faster, its business value is that the customers are happier when using the product. It is for the marketing department to decide wether that is worth it.
I would not bother too much with figuring out the exact numbers, they are not important. You should for yourself decide wether something is useful or not, if you are an experienced programmer I think this intuition will be right. Almost always, tooling will reduce your technical debt.
Tooling is not only automation, it is also process documentation.
I appreciate this reply a lot. This type of situation is a new one for me, I guess I should just bring up the subject as a whole and see how it goes. I hope I don't run into too much resistance since it will result in a short term decrease in deliverables.
It looks like you're trying to do the right thing here, even though there is no boss or peer who understands exactly what you're doing and can appreciate that fact. Kudos for that :)
To echo tinco's comment, do not try to explain the intricacies of what you're doing to your customers. Put yourself in their shoes and think about what is important to them. Explain just the "end results" of your tooling, emphasizing the points that are important to them and leaving out everything else.
For example, you could say that the caching rework will improve the performance of the system, software-defined infrastructure will ensure minimal downtime in case there's a hardware failure, etc. These are all benefits your customers will understand, even though they may not care or understand how exactly you will achieve them.
I work at a university developing research software (primarily - some is also external customer facing). My customers are internal customers, thus profitability and other business measures are not directly my concern.
The biggest issue I face with this is that my customers are non-technical people, so if I were to tell them that our infrastructure is now software defined and I have implemented analytics that will allow me to optimise the caching layer, they will most likely look at me with a puzzled expression and perhaps wonder what I'm actually doing since those things don't provide direct value to them.
The types of internal tools I am thinking of are things like; analytics, automated deployments, CI server etc.
One comment suggested I do a simple calculation like any other business decision. This is something I cannot for the life of me work out how to do. Internal tools will increase my efficiency in the future, so I guess at best I could estimate a payback time for some of these tools (like automation). Even so, how short a payback makes it worthwhile? For other tools, like analytics, how can this type of calculation be made?
Additionally, there are some things that are the "right way" to do things, such as software defined infrastructure vs managing it manually (which I currently do). Investing time in this won't have any immediate payback, but is nice to have in place in the case of a large failure when I need to recover quickly. These types of value calculations for me are not easy to make.
sourthyme, I like the idea of spending one day a week working on this stuff. Perhaps I need to have a conversation with my bosses/customers about this and try to explain to them the value that internal tooling will bring.
Thanks for the answers so far, please keep them coming.