I read about a certain company requiring their engineers to work field shifts, with the intent of improving the software quality. The online reaction has been interesting, with one camp saying it's other duties as assigned, and another camp saying the work contract can't be unilaterally altered. Other arguments and opinions are being shared; here's mine.
My experiences as a database administrator in an SAP shop could have happened practically without leaving my cubicle (or home, as it would have been now) with all user contact being filtered through several people, or email chains, or anecdotal stories from whomever. Never seeing or hearing from the customers leaves one to depend on performance monitoring tools and techniques like viewing memory, CPU or I/O levels, down to deeper dives with task managers, profilers, and trace/debug/crash analyses. For a technically driven person, that can be rewarding, and for introverts especially, interfacing with "the [GU] interface" is emotionally easier than talking to a demanding person (to use one euphemism).
As a person who believes they have good intent towards not [just] themselves but towards others, close and far, and for things beyond human, like life on earth, the dolphins, what have you, I want to go beyond the code or data. Connecting with a person who benefits or suffers from the enterprise applications I'd been a part of felt better to me when I could help them; I'd also feel bad if my well-intended changes turned out to make their job worse. Down to case specifics, as fairly as I can report from memory, the record books having been left behind in a prior downturn.
R/3 ramp-up
Initially, on the big ramp up, developers and lead department people (superusers, sort of), sat near each other, attending meetings as well as hallway and cubicle conversations. That streamlined the turnaround time when prototyping huge new modules. Working alongside on a daily basis conferred an automatic familiarity and collegial attitude whereby the most important steps were prioritized because of the focus level at such a juncture.
Stabilization
Later, though, when the basic foundation (not basis, directly) was set and the teams grew and moved to their own spaces, tuning became harder. One well-known, and common at the time, challenge was sales order save time. It was worse than linear, and with various subroutines, customizations, and gargantuan scope, representatives waited minutes for each transaction. I exaggerate only from memory, now. I ran traces, looked at ABAP, talked and emailed people, and came up empty.
Driving to their location, getting a chair near their workspace, and a good bit of quality time directly with them had multiple benefits. I could see what their limits and talents were, like for example juggling application servers until they connected through the fastest one available (we had kept old machines running after buying new ones as it seemed to scale, in theory). And they knew I was trying to help them, not just sitting behind a task list elsewhere.
Sadder moments were going to sites that had been brought kicking and screaming into SAP after having a different solution provider and being satisfied with their on-premise response time. And, it got worse when those sites were U.S. manufacturing facilities and global economics drove someone to decide they'd be out of work.
Conclusions
If the goal of putting an engineer in a site or field role is only to have their effort supplement one specific trade, that seems unreasonable. If the goal is also to improve the application by serendipity I would not expect that to be a good investment. If the result is users feel welcomed to give performance or quality feedback, I'm in.
