This is one of those places where I agree with the point the author is making, but I don’t really agree with the path they chose to get there… The bottom line problem is this—government, companies, and even individuals (yes, that means you and I) tend to slip into a mode of treating people as objects which either cost something, or produce something. From many perspectives, it’s easy to treat people as units of information, work, cost, etc.—but when you cross the line from using this as a useful abstraction to actually seeing people as an abstraction, then you’ve cross a line you shouldn’t be crossing.
The post Worth Reading: Employees are Human Beings appeared first on 'net work.
Talk to any modern IT person about shifting the landscape of how teams work and I can guarantee you that you’ll hear a bit about DevOps as well as “siloed” organizational structures. Fingers get pointed in all directions as to the real culprit behind dysfunctional architecture. Perhaps changing the silo term to something more appropriate will help organizations sort out where the real issues lie.
Silos, or stovepipes, are an artifact of reporting structures of days gone by. Greg Ferro (@EtherealMind) has a great piece on the evils of ITIL. In it, he talks about how the silo structure creates blame passing issues and lack of responsibility for problem determination and solving.
I think Greg is spot on here. But I also think that the love of blame extends in the other direction too. It is one thing to have the storage team telling everyone that the arrays are working so it’s not their problem. It’s another issue entirely when the CxO-level folks come down from the High Holy Boardroom to hunt for heads when something goes wrong. They aren’t looking to root out the cause of the issue. They want someone Continue reading
A friend of mine sent me an interesting problem:
I noticed recently that my IOS routers aren't sending ICMP (unreachable; frag needed) messages in response to too-big IPv4 multicast packets with DF-bit set. They're just dropping these packets silently, breaking PMTUD.
Unfortunately, that’s not a bug but a FAD (Functions-as-Designed).
Read more ...Infrastructure doesn’t matter.
That’s what we keep hearing, right? The ongoing effort to commoditize infrastructure has generated a lot of buzzwords and clickbait taglines, and this is one of the biggest.
IT infrastructure has had a long history of hero culture, and it’s easy to make the assumption - given how low many of these technologies sit in the stack - that we are the important snowflakes and that we run the whole show. The reality is that we don’t, and every time an application engineering team has to hold a series of meetings on how to properly work on the existing infrastructure, that is time spent not creating new features.
The reality is that the underlying infrastructure never stopped being important. The call to simplify these layers was never borne out of a desire to sweep the carpet out from beneath ones own feet. It was a call for help; application teams barely have time to meet the feature requirements laid out by the business, and having to deal with downtime or overbearing change management procedures makes a bad situation worse. The business is not measuring software project success by the number of challenges they overcame on our way Continue reading
Infrastructure doesn’t matter.
That’s what we keep hearing, right? The ongoing effort to commoditize infrastructure has generated a lot of buzzwords and clickbait taglines, and this is one of the biggest.
IT infrastructure has had a long history of hero culture, and it’s easy to make the assumption - given how low many of these technologies sit in the stack - that we are the important snowflakes and that we run the whole show. The reality is that we don’t, and every time an application engineering team has to hold a series of meetings on how to properly work on the existing infrastructure, that is time spent not creating new features.
The reality is that the underlying infrastructure never stopped being important. The call to simplify these layers was never borne out of a desire to sweep the carpet out from beneath ones own feet. It was a call for help; application teams barely have time to meet the feature requirements laid out by the business, and having to deal with downtime or overbearing change management procedures makes a bad situation worse. The business is not measuring software project success by the number of challenges they overcame on our way Continue reading