You can lead a horse to water, as the saying goes, but you can’t make him drink. This is an important saying, but it lacks the logical follow-up question: “So how do you make sure you can still get to town?”
This came up in a discussion during my recent DSC/DevOps Camp. One Camper had spent a great deal of time building out new tooling, with a goal of building a strong “infrastructure from code” system as well as a continuous integration pipeline for his developers. His first major hurdle?
His team didn’t care to learn about version control. They literally just weren’t interested.
This presented something of a block, of course, because it meant his team wasn’t interested in learning to use the new tooling, let alone using it. We talked for a bit, as a group, about some things you can do to combat this situation. We pointed out, for example, how you could get executive buy-in, and make performing these new tasks part of the job description. I argued that while this was a common approach, it was essentially weaponizing someone’s job description against them. I argued instead that you should just sit down with those people and explain why they didn’t need to work here anymore – it’s a more honest approach when you’ve got assets that just aren’t meeting the mission.
But, at the end of the day, it’s an engineering problem, albeit a people engineering problem, which we IT folks aren’t always adept at.
As you sit down and start conducting risk analysis for a new project, don’t let your IT brain go, “oh, people problems – let’s ignore that.” Focus on those people problems. Identify them. Decide how to mitigate them. And have an honest discussion with management about them – “look, guys, a lot of people aren’t going to be able to stay on the bus for this one – do we really want to force them, or do we need different people?”
And engineer a solution. “Look, our people hate change – they’re not going to want to learn these new tools.” Fine. Do you take the approach of, “how do we force the horse to drink,” or do you take the approach of, “Imma stick an IV in this horse’s ass and drip water into his bloodstream.” In other words, what can you do to not have to make people do what they don’t want to do? How can you further engineer the solution – to get back to the original example – so people don’t have to learn to use the source control system? Can you integrate it more automatically into their existing processes?
At some point, this mitigation will start to cost more – and that’s where you want to get to. “Boss,” you can say, “our people aren’t going to be on the bus. I can create a bus that will materialize around them, and it’ll cost this much. Or, I mean, we could get people who’ll get on the bus. What do you think?” Bosses like options, and they like options with numbers attached. Just turn it into a business problem, and offer business solutions.
(Also, thanks to everyone for the birthday wishes!)