Strategic CIO // Executive Insights & Innovation
Commentary
12/9/2013
09:06 AM
Connect Directly
Twitter
RSS
E-Mail
50%
50%

The Upside Of Hostility

The defining quality of the DevOps movement can challenge the default division of labor.

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.)

Previous
2 of 2
Next
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Coverlet
50%
50%
Coverlet,
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.
bchristian441
50%
50%
bchristian441,
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.
cbabcock
50%
50%
cbabcock,
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.  
ChrisMurphy
50%
50%
ChrisMurphy,
User Rank: Author
12/9/2013 | 5:31:54 PM
"Experience"
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
50%
50%
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.
RobPreston
50%
50%
RobPreston,
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. 
The Business of Going Digital
The Business of Going Digital
Digital business isn't about changing code; it's about changing what legacy sales, distribution, customer service, and product groups do in the new digital age. It's about bringing big data analytics, mobile, social, marketing automation, cloud computing, and the app economy together to launch new products and services. We're seeing new titles in this digital revolution, new responsibilities, new business models, and major shifts in technology spending.
Register for InformationWeek Newsletters
White Papers
Current Issue
InformationWeek Must Reads Oct. 21, 2014
InformationWeek's new Must Reads is a compendium of our best recent coverage of digital strategy. Learn why you should learn to embrace DevOps, how to avoid roadblocks for digital projects, what the five steps to API management are, and more.
Video
Slideshows
Twitter Feed
InformationWeek Radio
Archived InformationWeek Radio
A roundup of the top stories and trends on InformationWeek.com
Sponsored Live Streaming Video
Everything You've Been Told About Mobility Is Wrong
Attend this video symposium with Sean Wisdom, Global Director of Mobility Solutions, and learn about how you can harness powerful new products to mobilize your business potential.