“Don’t forget the human element!” was the mantra of a former boss I had in publishing. "Even for a technology publication?" had been my initial feeling. But this boss wanted to turn our trade publication into some techie version of People Magazine. And soon enough, it crystallized for me that without the human element, you’ve killed your story before it's even begun.
Not surprisingly, any successful change in your IT infrastructure necessitates realigning your staff to your business goals. As the senior director of applications pointed out in the first post of the series, his application and engineering teams, along with the company’s marketing teams, needed to be oriented toward the customer, the final arbiter of whether the services or products they are providing end up a success or a failure. In other words, if he had neglected the ways in which people connected with one another, he might have just ended up with fast & powerful, but ultimately underutilized, technologies.
But what about the systems side of things? My college roommate, “Sue,” a network monitoring engineer, told me the other day that the more complex the infrastructure, the better IT Ops people you need.
But Sue then brought up what she calls the “eternal issue” with all operations centers:
Generally, good [operations folks] want to move into engineering.
She did agree that better monitoring would help, but “folks in general cannot articulate what they want other than ‘everything,’” she quipped.
But situations do occur where the IT organization has to move beyond the silos in order to serve their customers. Recently, Zenoss interviewed a senior IT manager at a Fortune-500 level financial services provider about the drivers behind his firm’s IT staff “re-org.” This man’s responses suggested to me that focusing on a customer’s needs may ultimately lead to ops folks feeling less marginalized and more likely to feel that they’re part of a greater team.
1) Facing Resistance
This senior systems manager has a lot to oversee. His IT environment is distributed across multiple data centers and most of the infrastructure is virtualized. He had “tons of delivery teams,” including specific teams dedicated only to VMWare, Windows, Unix, SQL, and Oracle, among others.
And these various tentacles of his IT organization used a bunch of different monitoring tools, many of which had a long history within the various silos where they were used. This senior manager said his goal was to “provide our service at a reduced cost” and “improve efficiency in our ability to deliver financially for the company,” but “resistance to change was a factor.”
The manager said that until recently:
The value of enterprise monitoring wasn’t realized; it was more of a responsibility we had to provide.
Then the firm’s sales team was working to land several big new clients, most of which had needs that couldn’t be met unless his team developed new capabilities.
2) Reorganizing for Value and Growth
Apparently these new clients required a new level of visibility into the services this financial firm would provide them. This opportunity to grow the firm’s client base and increase their revenues seemed a damn good reason to re-evaluate what his IT team could deliver, and how they'd need to be organized to deliver it.
So he “re-architected” his org chart by dividing out the operational/deliver side from the engineering/architecture side, because the skillsets were so different. The engineering team would act as consultants and take charge of consolidating tools and defining what could be offered to customers. The engineers would focus on gathering relevant information, figuring out an implementation that would hit capability, time and cost targets, and then develop and document best practices for everyone to follow.
The operational/delivery staff would then collaborate with the engineering team to migrate from older tools to newer ones, fine-tune operational thresholds, perform the needed change management tasks, and keep everything in the infrastructure running smoothly.
3) Cooperating for Growth
Is this just creating a new segregated silo? Given my friend Sue’s view that most good Ops people want to move into engineering, I was skeptical about the implied benefits. But after hearing the manager's entire explanation, I saw he was taking a similar course of action as our senior director of applications did in the first post of the series through sifting and recombining his teams to better address client needs and make sure nothing important got starved.
This all reminds me how important IT generalists are becoming in these increasingly dynamic environments. And this engagement of every member in the organization -- that “human element,” if you will – may ironically lead to more fluid and productive IT organizations in the future...
