But in that same vein, recognizing how people operate means you can tweak or build a process to work with them and get results you want.

I'm not in a technical role like most people on this site, but I'm often in between those departments/their products and the consumer as well as the rest of the company. I think the mistake a lot of people in dev roles make is building a system that functions and think is good, and they need to bring the people to the process. But that's not how people work. You can maybe get a person, maybe even a few in line with your designed process. But when you have groups of people it becomes impossible.

Take that DevSecOps person above. Their solution to entire teams not using their process is to oust the leadership and bring the team to heel. I don't think that people take the time to think how they can alter their process to get the people more likely to work with it to get the results they want. As you said, people go the path of least resistance. You have to build your product to the user, not the other way around because the "people" aren't going to change.

My example: We had a process our level 1 team members needed to follow when filling out tickets. Most of the time, no big deal. Our system means their tickets need to be filled out and submitted almost immediately upon completion, they can't just wait around until the end of shift. It's a lot of real-time work. Occasionally we'd get hit by huge numbers because something vital broke and they're our front line in dealing with the communication, then these tickets would not get filled out properly in their mad rush to get them all submitted so they can move on. Every field not filled out correctly breaks our reporting, which is vital for us. Macros were no use because they could only fill out generic info and not any of the information we really needed. Their managers tried meetings and punishment and rewards, but when shit would hit the fan, inevitably the proper protocol would be the first thing to go to keep the operation running.

So I go in, take a look at the process start to finish and talk to the team about what specific things make it harder to complete in a crisis. And then I went and created a "mass issue" ticket form to use for those scenarios instead. When something major breaks and the team is flooded with these calls and they have to go through 4-5 at once every 10 minutes, they tick a box and get a new form with just the vital info and the ability to group as many issues on it as they have. Now they can group like issues together and fill out a single ticket. Their time is saved and we still get the precious data we need. Because we built our system to work with the user and made the path of least resistance a path that works.

But I have an advantage. I now work in a tech-adjacent role but I've spent my life working with people, not technology. So I get to bring that viewpoint to the job where most people around me have never really given it much thought.