IT loves its fads.
One of the more recent ones is the movement from “project to product” orientation. The trend is closely aligned with DevOps and Scaled Agile and purports to help organizations break through the bureaucracy and long-held project-centric metrics and attitudes.
Taking a product orientation, so the theory goes, helps organizations shift their focus away from timelines and deliverables and towards business outcomes and customer responsiveness.
These are, of course, good things. But will this approach deliver IT organizations from a project mindset sinkhole to customer-centricity nirvana?
I believe it’s a question deserving of thoughtful deliberation, especially when you consider that Apple, arguably one of the most successful product companies in the world, doesn’t seem to adhere to this approach itself. Instead, the company relies on a functional organizational model rather than product-centric business units — and cites this structure as one of its sources of innovation prowess.
Its approach, therefore, provides a compelling insight into where this project-to-product approach might go off the rails for IT organizations — and how to address its shortcomings.
From Projects-to-Products
For the record, I think that the general movement from a project to a product orientation is a good thing.
I’ve spent at least a decade of my life managing large projects and ran face-first into the bureaucratic bungling of project dogma more times than I can count. Most of the time, the focus was on anything but actually delivering a meaningful business outcome.
So I totally get it and applaud both the motivation and the intent. And, much of what has been written on the subject is well-meaning.
As Mik Kersten, author of Project to Product: How to Survive and Thrive in the Age of Digital Disruption with the Flow Framework, explained to The Wall Street Journal, “Tracking activities and budgets provides a false sense of security…Worse yet, baking in risk and spending decisions up front may delay teams in incorporating feedback as the initiative progresses.”
The challenge lies with IT’s propensity to use every new idea and management construct as a blunt force weapon — mainly on each other.
Increasingly, I’m seeing people talk about the need for permanent product teams or the complete product-centric restructuring of the IT organization. The DevOps movement, along with several other modern approaches to IT management, has long looked to large tech companies as inspiration. And, in fairness, many of them end up looking like product-centric organizational structures.
But there are two potential problems with using this as inspiration. First, many tech companies have a product orientation because they really only have a single product they’re delivering to the market. The more significant difference, however, is that despite the mantra that “every company is now a tech company,” the reality remains that enterprise IT organizations ARE NOT tech companies.
The demands, politics, and complexities of running an enterprise IT operations are vastly different from those that face a tech company’s technical team. To expect, therefore, that you can simply take what works for one type of organization and transplant it into another as an off-the-shelf playbook is folly.
And it’s why Apple’s story is so instructive.
Apple’s Functionally-Oriented Innovation Engine
Late last year, The Harvard Business Review published a fascinating analysis by Joel M. Podolny and Professor Morten T. Hansen entitled, How Apple is Organized for Innovation, which explored how Apple’s organizational model serves as an innovation engine.
It describes how, upon his return to Apple in 1997, Steve Jobs found a dysfunctional structure organized by business units. These business units were constantly fighting with one another and, in Jobs’ estimation, stifling innovation. So he ditched the entire model and went to a functional hierarchy organized around expertise and operating with a single P&L.
What the analysis points out as most striking, however, is that Apple has maintained this functional orientation ever since, even as it has grown to be one of the largest companies in the world.
What Jobs believed at the time, and what Apple has proven since, is that an organizational model that gets in the way of having the best people work on problems and efforts that most need their expertise will inhibit innovation. Instead, organizations that want to move fast and innovate need a model that will eliminate in-fighting and ensure cooperation, particularly when “companies [are] facing tremendous technological change and industry upheaval.”
Sort of sounds like the situation facing enterprise IT organizations, right?
And therein lies the issue with how the current project-to-product approach is evolving. As it morphs into calls for dedicated product teams or outright product-centric restructuring, it risks replicating the business unit model approach that Jobs saw as an innovation killer.
Essentially, it merely replaces one type of rigid hierarchy for another. And that rigidity will ultimately threaten an organization’s ability to pivot — no matter how good the intention.
Expertise, Details & Self-Organization
Rather than taking a direct product focus, Apple’s approach makes the case that the best way to create innovation and enable adaptability is by consolidating expertise and then making it available to whatever effort may need it.
For example, Podolny and Hansen report that Apple has over 600 camera experts working in a single functional unit, which, because Apple makes several products that require camera technology, “would be scattered across product lines if Apple were organized in business units.”
Instead, Apple’s approach is to centralize and encourage that expertise so it can apply it to its greatest advantage. “To create such innovations, Apple relies on a structure that centers on functional expertise,” write Podolny and Hansen. “Its fundamental belief is that those with the most expertise and experience in a domain should have decision rights for that domain.”
Doing so, however, demands that you change the way you manage so as to overcome the insularity that a functional hierarchy can create — and the reason that there’s a push toward product-centricity in the first place.
Apple achieves this using two fundamental leadership constructs: a relentless focus on the details and an informal form of self-organization.
Relentlessly Sweating the Details
One of Apple’s principal ways to accomplish this balance between centralizing expertise and avoiding ivory towers is by demanding that its leaders are “experts leading experts.”
By investing significant expertise within its management layers, it enables rapid identification of both challenges and opportunities, and helps avoid the delays that happen when leadership sees themselves as a management class and cannot engage at a detailed level.
Informal Self-Organization
What is most striking about Apple’s organizational approach is how this focus on expertise and details creates an informal sort of self-organization.
Podolny and Hansen explain that a team’s reputation acts as a “control mechanism in placing bets.” Functional teams assert themselves based on the depth of their expertise and establish credibility based on their reputations over time, enabling them to advocate for how the organization can best leverage their expertise within its various products.
In effect, this expertise and detail-driven approach create an ad-hoc form of self-organization in which teams are coming together to debate and explore how to best deliver innovative solutions to the market.
Mindset Over Structure
The big takeaway is that the great risk with the project-to-product trend is that organizations will miss the point. While the desire to move from project-oriented metrics and deliverables to a focus on the customer and business outcomes is fantastic, leaders are putting too much emphasis on the structural elements of this shift.
I am wary that too many organizations will merely attempt to create permanent or semi-permanent product teams (or spend months doing a full restructuring) only to effectively move their problems from one foot to the other.
As Apple’s structure and approach show, it’s the mindset rather than the structure that is most important. IT has a long history of attempting to restructure its way out of challenges — with consistently bad results to show for it. As an industry, we must take care that the movement from projects-to-products isn’t just a replay of this sad scene.
I believe that most IT leaders can find much of the value they seek by putting more energy into propping up and celebrating the expertise within their current functionally-oriented organizations and then using product-centric efforts to shift the organization’s mindset away from producing deliverables to delivering outcomes.
This mindset shift, far more than any structural change, will make all the difference.
Tag/s:Business TransformationCreativityFuture of Work
