The Upside Of Hostility - InformationWeek

InformationWeek is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

IT Leadership // CIO Insights & Innovation
09:06 AM
Connect Directly

The Upside Of Hostility

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.

That hostility is woven through every pragmatic answer to scale, a simple idea that's brilliantly captured by the diagrams of Emily Leahy-Thieler and Kristopher Thieler (sprinkled throughout this piece).

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.

[Does your outfit need a speed boost? Read 5 Ways To Turbocharge Innovation.]

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.
1 of 2
Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Strategist
12/18/2013 | 5:43:39 PM
Re: That which we call a rose...
Most break-fix teams are a response to inadequate quality processes on the dev side (whether internal or vendor).  So it's not a business or customer problem per se.  In Venn-speak, break-fix is a reaction to the lack of overlap in two critical functions.  And it's the wrong reaction because it fails to engineer an intentional overlap.

As for new/ehanced-features-as-business-problem, that's too vague for me to try to be helpful.   I'd need more information about your company's business- and customer context.  If you're unconstrained by your company's social media policies, post more detail here.  Otherwise, feel free to reach out to me via email.
User Rank: Apprentice
12/18/2013 | 4:34:38 PM
That which we call a rose...
I like the thought exercise and was hoping you would post an example solution.  This is particularly timely as my company is making another "tweak" to the IT organization.  If you explore the original statement for a business problem to solve, there are two that spring to mind: support the application by fixing bugs (including ones induced by the manufacturer releasing new versions of the platform), and support the business by delivering new or enhanced functions in the application.  Niether sounds like a good fit to name the problem and the team.
User Rank: Strategist
12/10/2013 | 12:25:16 AM
Much easier said then done
This is one of the best commentaries I've read on the overall problem of business, and the IT business in particular. We've not made much progress anywhere, but if I could name an area, it would be in DevOps. The nature of the barriers is understood, the need to surmount them, liikewise. A few willing steeplechase enthusiasts (overcoming one barrier is not enough) have actually been able to do so. They've proven the value of the concept. Can we sustain the gains? Prevent recidivism? Ummmmm, maybe, maybe not. But we have to keep making the specialist more of a generalist, and the generalist has to keep learning new and specifically useful things in his moment in time.  
User Rank: Author
12/9/2013 | 5:31:54 PM
I like the focus on experience, since it's quite the trendy word. Too often "experience" is about copying some other company's experience (per the milk foam over analytics), even though many times what customers value is having as little "experience" as possible -- get my thing done and get out.
Lorna Garey
Lorna Garey,
User Rank: Author
12/9/2013 | 11:34:57 AM
"Engineers" is a scary verb
Engineers and other left-brain types tend to underestimate the stomach-churning feeling that the concept of trying to understand exactly what developers (or [insert tech here]) actually *do* instills in a typical generalist. And, technologists like to encourage this state of affairs by sprinkling acronyms like cinnamon on a pumpkin latte. That's a big part of the problem, I think.
User Rank: Author
12/9/2013 | 9:43:44 AM
Adaptive Specialists
Adaptive specialists. I think you've coined an HR term, Coverlet. Without having put a name to it, I find myself looking for just such qualities in an editorial hire. 
11 Ways DevOps Is Evolving
Lisa Morgan, Freelance Writer,  2/18/2021
Graph-Based AI Enters the Enterprise Mainstream
James Kobielus, Tech Analyst, Consultant and Author,  2/16/2021
What Comes Next for AWS with Jassy to Become Amazon CEO
Joao-Pierre S. Ruth, Senior Writer,  2/4/2021
White Papers
Register for InformationWeek Newsletters
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you.
Flash Poll