[Aeolun]

Yeah, going directly to the end user is almost certainly best. The amount of times you find people spend 2 hours of their days on what would be literally a 5 minute fix (my favourite being the select with a thousand options that wasn’t alphabetically sorted) is mind blowing.

And all that just to preserve some egos. Though to be fair, in some cases users do request crazy stuff, you just shouldn’t listen to them and look at what they actually do.

[froindt]

I love finding those high impact, straightforward changes! I support dozens of spreadsheets at work and am the person people call when one breaks.

* Conditional formatting cut a 2 hour weekly job down to under 5 minutes.

* The intern, who was hacking away and learning VBA, spent around 20 hours and was able to automate 4 hours per day of manually retyping info between Oracle and a couple spreadsheets. Would have been about 2 hours if he knew VBA going in, but he learned a ton.

* 2 hours standardizing a spreadsheet format and making a custom macro to shift values by x rows and y columns turned a monthly 2 hour, tedious update task into 2 minutes.

[BostonEnginerd]

Every company needs one person who can make simple changes to inefficient business processes and save a ton of time.

[Ntrails]

I feel like there are a couple of obvious problems that exist:

- Knowing that such a person exists - Knowing that the fix is simple - Knowing that they will have time to look at a thing quickly

I'm a person who will answer any question on any topic if asked, and help anyone with anything if I have the ability to do so. That's because I enjoy doing stuff in general and my long projects aren't meaningfully going to suffer. Counterpoint, the only people pestering me on this are friends / close colleagues and it wouldn't scale.

I reckon that the net benefit of being willing to do that to the company is positive, but honestly I'd do it anyway because sometimes 2 hours hacking on a powershell script is a welcome distraction!

[WorldMaker]

Similar to the "users request crazy stuff", managers of users request crazy stuff based on what they think their users need. Stuff that goes up and down two very different reporting chains (up the users' then back down yours) is almost always going to be some weird telephone game crazily divorced from reality.

"How is the user actually using this software?" is sometimes a weirdly hard question to answer correctly in reporting chains.

Then when those reporting chains get siloed due to budgets and in-fighting and over-complicated "change management procedures" (due to often over-zealous risk aversion, maybe to avoid losing budgets), it's far too easy to find yourself not developing for the actual users but for some ideal "manager-user" that doesn't actually use the app day-to-day (or maybe even at all) and instead believes the map is the territory. (Those that think the issue tracker about the app is the status of the usage of the app, or worse that PowerPoint screenshot demos of the app are all that matters and tells them everything about how the app functions.)