Try something like "In order to write better tools and automation, I need to empathize with the people using the tools and experiencing day-to-day pain. Can we find somebody who is willing to let me watch over their shoulder for a few minutes on one day?" Note the implicit bargaining for small amounts of time and only small intrusion, as well as the understanding that you are not a decider, but an observer; not an automator, but a pain-reliever.

There is a strange desire on this site to assume good faith. I have no idea where that comes from; nearly everybody is clearly posting with a heavy, thick personal bias. I suspect that folks only feel that they are arguing in good faith, and that their feelings blind them to their biases.

Here, I will show you. https://news.ycombinator.com/newsguidelines.html

I ask because I directly attribute almost every bit of "luck" I've experienced to people acting in good faith. It's literally been the most important decision I've ever made and stuck with.

Personally, I have no energy for discussions where people assume the worst by default. That falls way too close to "someone is wrong on the internet" for me. It's easy to find people to disagree with, and difficult to find smart people that can illuminate why you might be holding onto incorrect assumptions.

I've also spent time in our sandblast units and our loading docks and sales team.

How can I architect and build good software if I don't have a good understanding of the domain and you can only get that by immersing yourself in it head first.

I'm lucky in that my boss cottoned onto the fact we get better software when I see the problem in the raw and not just his interpretation of the problem.

Wouldn't work for everyone, we are a small production/import company so it's possible for me to get the basics of each users role (and I can physically go ask them if need be) but it's a huge win imo if it's possible.

The woman who had been wasting this time for years came up and hugged me in tears. No one was getting fired but I'd just freed up enough time that she didn't have to work overtime everyday. It was such a simple change and lifted such a weight off the users shoulders that went undone for years because nobody actually watched them using our software.

Unfortunately someones authority was undermined and I was let go a few weeks later.

That is so depressing.

I have a huge amount of latitude in how I spend my time so if boss sees me in the loading dock scanning deliveries he assumes that I'm doing it for a good reason.

One of many reasons you'd need a crowbar and a tub of grease to get me to leave, I've had offers with 20% better compensation or more including some developer management roles but never even considered them, I'm well paid for a developer relative to the local market, I work a 37.5hr week, week in/week out and my work is both appreciated and has a measurable impact, it's close to programmer heaven (except for the mess I inherited but that's slowly getting sorted).

There is more to life than money including actually having time for a life.

Show, don't tell.

If I want something looking repetitive working smooth, I‘ll let my best devs do the work themselves for a week and dig their way out of it.

Heck, that‘s exactly how I got serious about coding in the first place. The guy in the post automated his job, decided not to tell anyone and played games all day. I told my employer about my automation back then and they were like - „so you wanna quit now or join Engineering?“

Whatever floats your boat — I‘m CTO by now.

Also, yes - anybody can do management, and anybody can do coding. Learning to do either effectively is a skill.

Are you just making these decisions off the top of your head? Or are you talking to people, having research done, soliciting feedback, etc? In the latter case, congrats, now you're a manager! :p (If you're at a small company, you've probably still got enough time to do some hands-on work too...)

IME bad technical managers don't occur at any higher frequency than bad engineers; I haven't worked in other industries to know what it looks like there.

But you get a lot more immediate pain working for a bad manager than next to a bad engineer...

Perhaps people are worried you'll automate them straight to a layoff?

There is a thing called "process debt", in the same way as technical debt, that some things are done manually. This can be mundane routine work, that might be up to 80% easy to automate, but allows for oversight and flexibility and often works with systems that are not trivial to work with. Other times the manual process is just cheaper to maintain than it is to invest in a "good enough" automation. You can also follow this by looking at the practice of offshoring and the amount of automation invested into offshored service centers (who benefit most from these solutions via specialization and scaling).

So even if the company hires a goddamn genius, if you want to automate stuff without breaking existing flows, you need quite a few months of understanding of the environment and the real needs of the process (business wise as well), etc.

And that's why managers think it's a joke idea.

(And it also comes off as extremely arrogant, because it's essentially calling your coworkers stupid by saying "I'll see something that you haven't noticed in years!")

It's also arrogant to assume that a fresh perspective will never yield fresh results.

I'm starting to think that the only way to work around the problem (if you actually are good at seeing things that the rest of the organization has blind spots for) is to become a consultant who is expected to suggest changes. Otherwise you will be stuck fighting against primate hierarchy instincts.

There's this saying in my country, roughly translated to "Guest for a second, sees a mile far" (sorry... it even rhymes and everything in Polish...)

Being immersed in something for a long time has a good chance of limiting your perspective to that thing only. While it's true that perhaps 90% of newcomers and their ideas simply miss the intricacies of the current process and would be disastrous if implemented, the remaining 10% is a genuine innovation which would never come from the inside.

Using your software for the intended work can be very eye opening. I have had many occasions where I had to use stuff I had written and quickly saw a lot of inconveniences that could easily be fixed. When I asked users about this they agreed but they never asked because they thought it would be a difficult change.

Recently I had to use our SAP system and there would be a ton of opportunities for small changes with huge time savings but somehow it seems they never trickle up to the devs.

That's what easy to miss when thinking in terms of "automation". Automating existing work doesn't move us forward very much. Making the work unnecessary is.