"Past outcomes are not indicative of future results" Just because they came back after 5 years doesn't mean it will be 5 years before they come back again. It was, in fact, quite unpredictable. We didn't want to be on the hook every time their data source changed the format of the data. If this work is so important, they need to work with the team pumping out the data to have it standardized and stable.
This was in an org that was sorely lacking programming talent, and management clearly did not want to hire SW engineers. There was always a lot more work than there were engineers for, so it was a continuous battle of demarcating boundaries. If you start doing SW favors, everyone will want it from you, and will push the upper managers to force you (or your team) to do it. None of this will matter for promotions, because SW was secondary to our jobs. Without a hard stance, you'll drown.
As another commenter said, it was an incentives problem. Right or wrong, good or bad, helping people with small scripts was not something that would ever be rewarded.
It was also a matter of principle: If you do someone a favor, and they come back to you with an attitude and insist you owe them because you did them a favor, you stop doing those favors for them. That was something I would see often in that org (even outside of SW work): If you do work for someone, they expect you to own it.
Overall, the culture was poor. But I've found elements of it in most jobs.
Judging from the comments, it's evident I wasn't clear enough: When I said "our customer", I did not mean an external customer, but an internal team. We were a service/expertise department that helped various teams in the company with our expertise (and the expertise was not software). This was all informal - there was no monetary accounting/SLAs for our services.
> As another commenter said, it was an incentives problem. Right or wrong, good or bad, helping people with small scripts was not something that would ever be rewarded.
I agree with you here. The long queues for internal dev support is indicative of high demand for that support. If the organization can’t or won’t staff properly to provide that support, both the users AND the devs are forced to make tough choices.
So the devs say “No” to requests (or it takes an inordinately long time to get done), and so the business users make their own tools.
This was in an org that was sorely lacking programming talent, and management clearly did not want to hire SW engineers. There was always a lot more work than there were engineers for, so it was a continuous battle of demarcating boundaries. If you start doing SW favors, everyone will want it from you, and will push the upper managers to force you (or your team) to do it. None of this will matter for promotions, because SW was secondary to our jobs. Without a hard stance, you'll drown.
As another commenter said, it was an incentives problem. Right or wrong, good or bad, helping people with small scripts was not something that would ever be rewarded.
It was also a matter of principle: If you do someone a favor, and they come back to you with an attitude and insist you owe them because you did them a favor, you stop doing those favors for them. That was something I would see often in that org (even outside of SW work): If you do work for someone, they expect you to own it.
Overall, the culture was poor. But I've found elements of it in most jobs.
Judging from the comments, it's evident I wasn't clear enough: When I said "our customer", I did not mean an external customer, but an internal team. We were a service/expertise department that helped various teams in the company with our expertise (and the expertise was not software). This was all informal - there was no monetary accounting/SLAs for our services.