[Reading time: 3 minutes 11 seconds]
If ever there was a novel about technology, it must be The Martian .
I mean, for the largest part of the book, the main character is literally the only human for millions of kilometres around. In fact, the only living organism (except for some potatoes and soil bacteria, I suppose. And (spoiler), they die). And he’s spending all day tinkering with his space station, or his escape vehicle. It feels like an American settler/explorer story, set in a different kind of wilderness, I suppose. A man and his carbon-fiber horse.
Yet the surprising thing is: even The Martian, which on the face of it only has a single person in it most of the time, and that person tinkers with tech all day, is about human relationships:
- The protagonist’s relationship with his present self
- The protagonist’s relationship with his past self
- The protagonist’s relationship with his future self
- The protagonist’s relationship with the memories of his crew members
…And that’s just before Earth makes contact with him again, and the circle of relationships gets wider.
There’s a lesson in here worth exploring: Technology is never about technology, it’s always about humans.
Allow me to illustrate. Let’s say you’ve decided to introduce Docker. Tech choice, right?
Except, people will have opinions about it. And not only that: far more crucially, their relationships will be impacted by it. Because each tech choice is also an architecture choice. And, as Mr Conway has expressed in the law named after him, organisation structure and product structure are inevitably linked.
So your choice of (say) Docker will have ramifications for how you shape your product, and hence for how your teams are structured, how responsibility is divided, for who talks to whom about what.
And it doesn’t even stop there. I don’t know if you’ve heard, but reliable sources tell me that humans have those confusing things called feelings. So not only do you need to worry about tech, and about org structure – you also have to need to worry how your coworkers feel about these changes.
Maybe the greybeard sysadmin secretly fears to be left out, made redundant by the young whippersnappers with their fancy cointainers. Of course he won’t say that out loud (perhaps not being aware of it himself), but he’ll find reason after reason why Docker is a bad idea, won’t work, he doesn’t have time to help in the adoption, etc etc. Or just outright sulk.
I don’t mean to paint a purely negative picture. Of course not everything is gloom and doom – the opposite scenario might also be true, and everybody is totally excited and eager to go for it. Great! Wonderful!
But the point is to consider these human aspects, and attentively work with them. There are no shortcuts, because humans are humans are humans.
This is why DevOps is hard: because it’s a complicated web of technology, people and organisations.
And… this is why DevOps is so powerful when done right. Because a decent adoption will take this bull by the horns. Not try to work against this human aspect (good luck with that), but work with it to harness its awesome power. Because if you get a bunch of smart people to not merely work alongside one another, but actually work together… hooo boy. I get goosebumps just thinking about it.
That’s why DevOps is so much fun. And why helping organisations adopt it can actually be intoxicating.