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.

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.
2 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. 
The State of Chatbots: Pandemic Edition
Jessica Davis, Senior Editor, Enterprise Apps,  9/10/2020
Deloitte on Cloud, the Edge, and Enterprise Expectations
Joao-Pierre S. Ruth, Senior Writer,  9/14/2020
Data Science: How the Pandemic Has Affected 10 Popular Jobs
Cynthia Harvey, Freelance Journalist, InformationWeek,  9/9/2020
White Papers
Register for InformationWeek Newsletters
Current Issue
IT Automation Transforms Network Management
In this special report we will examine the layers of automation and orchestration in IT operations, and how they can provide high availability and greater scale for modern applications and business demands.
Flash Poll