Commentary
12/9/2013
09:06 AM
Connect Directly
Twitter
RSS
E-Mail

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.



It's the corporate version of the greatest trick the devil ever played: convincing the world that the perfect complement to a specialist is a generalist. It's not. And anyone who tells you otherwise has questionable aspirations.

The perfect complement to a specialist isn't a person. It's a quality -- the same hostility to boundaries that makes DevOps the old leather jacket of IT.

If there's a skill associated with that quality, it isn't one that PhDs have. It's adaptability.

And that's the choice we have when hiring: between orthodox specialists and adaptive specialists, between orthodoxy and heterodoxy, the conformist and the guy with the can of spray paint.

Do I need to explain which of the two specialists lets the business problem determine where else they need to go deep? Which one draws from an eclectic set of traditions, accepts ambiguity, and is comfortable with contradictions? Which one understands the difference between the ability to change and the ability to understand change?

And before you confuse that last paragraph with my lifelong goal of genetically constructing a supernerd, this isn't about doing everyone else's jobs for them. Let's say you have depth in application development. The goal isn't to understand database buffer management better than your DBA or know how to configure a 10G network card better than your infrastructure partners. Rather, it's to understand the rest of the stack with enough depth to be able to challenge those peers. And they you.

It's that simple.

Once you're there mentally, you can take the next step. For the sake of the generalists, I'll keep it high level:

The problem is the name
A quick thought exercise. You're handed a 100-person mobile development organization. Your remit is to support your company's flagship app in two stores, Apple iTunes and Google Play. You do a quick skillset review and find that you have five different groups of 20 people each: business analysts, iOS devs, Android devs, services devs, and testers.

How would you draw your organizational boundaries?

-- Five teams: Analysis, iOS, Android, Services, and Quality?

-- Four teams: iOS, Android, Services, and Quality (with analysts sprinkled across each)?

-- Three teams: iOS, Android, and Services (with analysts and testers sprinkled across each)?

It's a trick question. Even though each bullet gets progressively better, the gun is still pointed at your head. What you're missing in the exercise are the two most critical pieces of information.

The first is your business context. What business problems are you trying to solve with those apps? So let's extend the exercise and say that you're in consumer banking and your app provides four basic functions: payments, deposits, withdrawals, and transfers.

Could those be your organizational boundaries -- a payments team, a deposits team, etc? That's certainly better than the kneejerk compartmentalization that over-values tech specialization. But something is still missing, especially when you consider that technology teams should be as fluid as the business problems that they're tasked to solve.

Payments aren't a problem. They're a business function. So having a payments team is the business version of tech's proclivity to have an iPad team. It's the default position -- specialization -- masquerading as business alignment.

Enter your second missing piece: your customer context. How are you trying to delight the customer? How do you plan to leapfrog your competitors around that business function?

This is how to use innovation as the center of organizational transformation. Name the problem, and make that problem the name of the team.

Strike fear in the hearts of all those managers who are "here but retired," because this name game makes the team's success criteria incredibly obvious. Built into this model is the anti-empire-builder's credo: Make yourself and your team redundant, and quickly.

Think about it. If your team (or team name) is around long, that's either a reflection of failure or that the problem was too broadly defined.

Anger management
Organizing by function is as fundamentally flawed as it is pervasive across business and technology. Tech might have different words for "channel" (i.e., stack or architecture) than lines of business, but ultimately we're all making variations of the same mistakes. On one side of the fence sit Banking Center and ATM executives and on the other, Infrastructure and App Dev executives.

The odd part is that both sides understand the value of the end-to-end view and both sides understand the constraints of silos. So awareness isn't enough.

If we're to maximize value -- the center of the Venn -- we need to engineer intentional overlaps. Yes, engineer them. Not a verb that gets used often enough by the C-levels.

And therein lies the final lesson of DevOps: Just as it has proved that operations is engineering, it could radically transform the discipline of management.

We need to challenge ourselves when we thoughtlessly make the easy, default choices and organize teams as we always have: around functional groupings. That's as effective as going to the same bar every night and complaining about your dating pool.

We need to rethink roles. We need to turn incentive structures on their heads. And we need to evaluate alternative models across the biz-tech divide and across industries.

And if all that doesn't work, well, we can always get back to giving our customers cappuccinos and neck rubs.

You can use distributed databases without putting your company's crown jewels at risk. Here's how. Also in the Data Scatter issue of InformationWeek: A wild-card team member with a different skill set can help provide an outside perspective that might turn big data into business innovation. (Free registration required.)

We welcome your comments on this topic on our social media channels, or [contact us directly] with questions about the site.
Comment  | 
Email This  | 
Print  | 
RSS
More Insights
Copyright © 2020 UBM Electronics, A UBM company, All rights reserved. Privacy Policy | Terms of Service