The defining quality of the DevOps movement can challenge the default division of labor.
Imagine that you walk into your dry cleaners and they've transformed the greeting area into more of an "experience" -- a cafe-like atmosphere, greeters with iPads, large flat-panel screens educating you about their new eco-friendly dry cleaning processes.
Your mind would reel, trying to reconcile thoughts like "who the hell is paying for this?" with "why does it smell like cappuccino in here?"
Wait. Did I say dry cleaners? I meant bank. I confuse the two because I've been in banking long enough to have lost the humility to recognize that we're glorified dry cleaners -- two equally banal scribbles on your weekly list of to-dos.
It is a symptom of scale when banks replace the modest lobbies of yesteryear with expensive Disney versions. The underlying problem is that management's default response to the complexities of scale is to divide labor by specialization, to organize talent by what they know versus what they need to know. And this process hardcodes organizational boundaries into functional roles, guaranteeing that teams either can't see or can't act on the end-to-end customer view.
This state of affairs is particularly pronounced for the too-big-to-fail crowd. Their senior executives correctly infuse top-level strategy with analyst-facing words such as cross-channel and omni-channel. But those words remain hollow because two levels down from Mr. Potter, the organization defaults to specialization: creating, validating, and rewarding roles that focus exclusively on a single channel.
That's why every big bank still has a banking center executive whose main job is to create "an experience" when customers walk in.
Enter banking centers with cafe-like atmosphere or, worse, a financial spa. Enter complete customer outrage when a previously free banking service gets tacked with a fee.
What's lost is completely obvious to non-bankers: the end-to-end view. The idea that customers are more than their narrow interactions with a single channel, that they channel surf from their teller interactions to their mobile phone to an ATM to a call center to online.
If it's so obvious, why does Big lack cross-channel integration? Why does each channel-hop feel like a completely different company? Why doesn't that power-tie-wearing barista at your banking center have the foggiest notion of your channel surfing data?
Because the money that might have been spent getting the barista insight into your end-to-end experience is now foaming milk.
And before you smirk at how poorly we're doing in banking, know that the root of this problem -- the blind adherence to specialization that calcifies dysfunctional organizational boundaries -- is endemic across industries, in both line-of-business and IT circles.
What follows is a proposal to restructure roles, departments, divisions, and even companies around the intractable business problems that they aspire to solve.
It's raining Venn I've been afraid to write about DevOps for fear of speeding its inevitable descent into the buzzword abyss. I'm a fan, not because it's some new answer (it's not), but because at its core DevOps is hostile to boundaries, the same quality that defines and drives our most transformative leaders.
The takeaway? The enterprise is a Venn diagram, and magic happens only in the overlaps. The irony, of course, is that DevOps limits its call for porousness (culturally) to just dev and ops. It might have benefited from a more ambitious name like BizTech. Or a more personal one like MeYou.
Not to fear, though, because as soon as DevOps started to behave like a social movement, it began to have similar spillover effects. Which is great because there's no reason the DevOps focus on culture, automation, measurement, and sharing shouldn't be applied with more breadth and depth across the enterprise.
Take the software development life cycle (minus Ops): analysis, design, development, testing. Isn't the best analysis produced when it overlaps with design, the best design with development, the best development with quality, etc? There's no step in this process that doesn't explode with value when the specialists in that area reach past their functional and organizational roles and into their adjacencies.
We all know this implicitly. Silo is a four-letter word. Always has been.
And yet, when managers are given the SDLC remit and handed a lot of employees, they immediately trap themselves in the 19th century construct of a manufacturing assembly line: analysts at the front of the conveyor belt, designers next, then developers and testers. All management needs at that point is a monocle and a bejeweled cane to "encourage" the riff-raff to converse, gentleman-like, with one another. If that approach doesn't work (and it won't), they can always pull together a new team, call it something grand like Architecture, and fill it with all the beautiful dreamers on the assembly line prone to losing a limb in the machinery.
If we're to break the cycle, we need to ponder this question: Why does management compulsively rationalize silo behavior as an efficiency play when its effect is just the opposite?
Dat boy got da debel in him Who do you suppose started the generalist/specialist debate in technology? All my money is on a generalist. More specifically, a project manager who used to be a specialist and traded it in when he realized his company didn't offer a lucrative technical career path.
We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.