[hobs]

At the last company I worked at they brought glad handers to take care of the execs while I the "low level tech" went around to people's cubes and spent 2-3 days talking to them, understanding their requirements (usually with NO meetings, just 1-1 after talking with their managers and leads.)

This got me the best feedback I have ever gotten, and I regularly implemented fixes and changes that made the C-levels rave about the product (because their entire staff was so surprised at someone giving a shit.)

I was quite impressed by my head of product's subterfuge, she was incredibly talented.

[WorldMaker]

At one previous employer, I got into some heat for being that "low level tech" that went directly to users' cubes and talking to them directly instead of waiting for stuff to filter up and then back down chains of command. The users were really excited to see some features they had needed for years finally implemented and all it cost them was buying a bored college intern lunch a couple times. The managers were so unhappy with me though for breaking protocol.

That job taught me a lot about what to avoid in a corporate culture, because of how dysfunctional that was that the more actual work I did the worse my reviews got and the more my managers seemed to hate/resent me being on the project. It was a situation I hope never to repeat in my career.

[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.)