The Upside Of Hostility

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.

{image 3}

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