On March 18th and 19th, an elite group of digital and technology executives from around the world gathered at the iconic Crescent Court in Dallas, TX for the Metis Strategy Technology Leadership Institute—a two-day, immersive experience designed to help high-performing leaders navigate the leap from execution to enterprise leadership. Executives from leading companies such as NRG Energy, Lenovo, Nationwide, Marriott International, ConocoPhillips, Union Pacific, Zurich, Cigna, Land O’ Lakes, and Ally came together to sharpen their leadership skills and expand their professional networks.
“What got you here won’t get you there.” That was the central theme echoed by Michael Bertha, Partner and Central Office Lead at Metis Strategy, as he addressed the cohort. “Many of these executives have built their careers on exceptional delivery—being in the trenches and driving results. But the skills that got them to this level aren’t necessarily the ones that will propel them into the C-suite.”
For senior technology leaders eyeing the top chair—CIO, CTO, CDO—there is no predefined playbook or certification that guarantees success. Chris Davis, Partner and West Office Lead, put it plainly: “There’s no MBA for making the leap from VP to the C-suite. Our Technology Leadership Institute provides a structured framework to help these executives craft a tailored plan for their ascent.”
Over two days, participants engaged in hands-on, collaborative sessions covering key leadership dimensions critical for rising executives. The goal? To build a personalized development roadmap that blends strategic acumen, executive presence, and business impact. The curriculum tackled:
But content alone wasn’t the defining factor of the experience—it was the relationships built along the way.
“No one succeeds in isolation. Every leader has blind spots, and those who advance know how to surround themselves with the right people,” said Alex Kraus, Partner and East Coast Office Lead.
To that end, the Institute wasn’t just about skill-building—it was about network-building. Participants openly shared their biggest development areas and identified peers in the cohort who excelled in those domains, forming personal advisory networks designed to last well beyond the event.
The bonds formed extended beyond the workshop sessions. On the first evening, participants gathered for a sushi dinner at Nobu, where conversations flowed from leadership challenges to industry trends, and even a few lighthearted debates over the best sashimi on the table. “The magic happens when the formal learning stops,” said one executive. “It’s in these moments—over dinner, sharing stories—that you realize you’re surrounded by people who truly get it.”
As the two-day experience wrapped up, executives walked away not just with a roadmap for advancement, but with a trusted circle of peers—a support system of high-caliber leaders ready to help each other navigate the next stage of their careers.
For those looking to make the leap, the message was clear: success in the C-suite isn’t just about what you know—it’s about how you lead, who you learn from, and how you create impact beyond IT.
Michael Porter, in his landmark 1996 Harvard Business Review article, “What Is Strategy?”, made a clear distinction: operational effectiveness is not strategy. While practices such as total quality management, benchmarking, and outsourcing can lead to significant improvements, they are easily replicated and do not constitute a sustainable competitive advantage.
For digital and technology leaders, a similar debate persists: operational effectiveness is not transformation. Many executives recognize this distinction and seek a dedicated transformation office to drive outcomes beyond efficiency gains and into the realm of true business model reinvention.
Porter distinguishes operational effectiveness—performing similar activities better than rivals—from strategic positioning, which entails performing different activities or performing similar activities in unique ways.
The same logic applies to transformation. Consider Amazon’s use of AI-driven demand forecasting and route optimization to reduce delivery times and inventory costs. While these improvements enhance efficiency, they are also easily adopted by competitors such as FedEx and UPS.
Now, compare that to Tesla’s over-the-air (OTA) software updates. Traditional automakers rely on dealerships and service centers for vehicle maintenance, recalls, and feature updates. Tesla fundamentally changed this model by enabling OTA updates, allowing it to fix issues, improve performance, and introduce new features remotely. This wasn’t just an efficiency play—it transformed the very nature of vehicle ownership, turning cars into continually evolving digital platforms. Rather than simply optimizing the existing automotive service model, Tesla redefined how customers interact with and experience their vehicles.
When organizations pursue transformation, they often jump straight from ideation to execution—focusing on refining existing systems and processes rather than redefining the activity itself. This approach can yield value but frequently results in a multi-million-dollar effort to do the same things faster rather than reimagining what is possible.
The “missing middle” is the set of strategic activities that occur between ideation and execution—steps that increase the likelihood of delivering truly transformative outcomes rather than just operational efficiencies. These activities include establishing a vision, reimagining experiences and processes, defining the holistic technical architecture, and devising a plan for managing delivery and change.
The magic of the “missing middle” is not derived from the activities themselves. None of them in isolation are novel; you are probably doing all of them in some form or fashion. Rather, the magic is derived from the order, rigor, and purview at which they are executed.
Take order, for example. A company that starts its transformation by designing systems and then tries to retrofit a vision based on the system changes they have proposed will likely overlook key aspects of the experience or opportunities to truly change how they go to market to serve a growing persona or channel in a differentiated fashion.
Similarly, a transformation that skips visioning to determine how success will be measured and how it ties to firm economics may suffer from an existential crisis, unable to articulate how its investment has moved the needle. Order matters, and it all needs to start with a measurable vision.
The rigor with which these activities are executed is another moment of truth. As the Chief Digital Officer of a Fortune 500 manufacturing client said, “Transformation is not a part-time job.”
Performing the missing middle correctly often requires a team of dedicated resources. Sometimes, this is simply a matter of capacity, and other times, it’s a matter of not having the proper skill set. Organizations that do this well dedicate full-time resources to establishing repeatable playbooks and executing the activities in the missing middle.
For example, a Fortune 500 manufacturing client recently enlisted 15 new full-time resources to stand up a transformation function and lead key transformation activities: strategy, experience, process and technical architecture, and change.
Despite their best efforts and intentions, a technical lead asked to design the future-state vision and experience off the side of their desk, while also leading architecture, will inevitably fall short. Cross-functional, cross-business-unit transformation initiatives that are intended to fundamentally change how a business operates or interacts with constituents deserve fully dedicated resources to execute the missing middle.
Last but surely not least is purview. For large, at-scale organizations, transformation efforts cannot succeed in a vacuum. It’s rare that something truly transformative won’t have its tentacles in various business units, functions, and other parallel transformative initiatives.
To effectively play the orchestra, there needs to be a centralized transformation function that defines “the music” that the various initiatives follow in conducting the activities in the missing middle. It should define the overarching guardrails for experience, business, and technical architecture for all of the initiatives in the portfolio. It should also have methods for maintaining ongoing dialogue with initiative teams so they can verify alignment with the guardrails and have visibility into execution to navigate portfolio-level issues, ensuring that the outcomes of one initiative complement, rather than conflict with, those of another.
The degree to which these capabilities are decentralized at the initiative or centralized at the portfolio level will vary based on the goals of the organization regarding consistency, governance, speed, and agility. Over time, most organizations settle in with a hybrid model.
If your transformation efforts feel more like an exercise in operational efficiency rather than a fundamental shift in how your business operates, it may be time to reconsider your approach. True transformation is not about doing the same things better—it is about redefining what is possible. A dedicated transformation office, equipped with the right order, rigor, and purview, can be the difference between incremental improvement and a true reinvention of your business model. By focusing on the missing middle and aligning strategic activities before execution, organizations can drive meaningful, sustainable change that extends beyond efficiency and into the realm of true competitive advantage.
At first glance, the shift toward product thinking may seem tailor-made for teams working on customer-facing digital products, like mobile apps or eCommerce experiences, where new features are envisioned in lockstep with business units that have P&L responsibility. But what about teams maintaining enterprise applications like SAP and Salesforce? Or those responsible for shared APIs, IT Ops, and core platforms, which serve multiple product teams rather than direct customers?
If these questions resonate, you’re not alone. Many organizations transitioning to a product operating model encounter a moment of reckoning, where technology professionals accustomed to a service-oriented approach begin questioning where they fit. The reality is that while the implementation of product thinking varies depending on the type of work, there are core principles that apply universally. Proactively addressing these nuances is key to ensuring adoption, mitigating resistance, and maximizing impact.
To successfully adopt a product operating model across the technology function, it’s critical to recognize that not all teams will work in the same way. The model applies broadly, but the composition of work, customer relationships, and team structure will vary based on the type of product being supported.
Product teams focus on customer-facing or business-aligned products—solutions designed for direct end-users, whether external customers, employees, or partners. These teams operate in close collaboration with business units, iterating on features that enhance experiences and drive revenue. Because they are continuously evolving their offerings, product teams typically allocate the highest proportion of their efforts to grow and transform work—building new capabilities, improving customer experiences, and responding to emerging market demands—while still maintaining the core functionality of their products.
Platform teams provide shared capabilities, APIs, and infrastructure that support multiple product teams. Their customers are often internal, ensuring that foundational technology services—such as data platforms, authentication systems, or integration layers—are scalable and reusable. The nature of their work is more evenly distributed across run, grow, and transform activities, as they must balance maintaining system stability with improving and expanding the services they offer to product teams.
Services teams maintain critical technology operations, supporting both internal users and other product teams. Unlike product teams that focus on innovation, services teams prioritize run activities—ensuring uptime, compliance, and operational efficiency—while still making measured improvements over time. Their primary responsibility is to keep core capabilities and infrastructure reliable while adapting to business needs and regulatory changes.
Beyond work allocation, these teams also differ in who they serve. Product teams work closest to revenue-generating customers, continuously improving their experience. Platform teams serve internal product teams, providing the foundational services that enable scalable innovation. Services teams support internal business users and the rest of the technology organization, ensuring critical enterprise functions run smoothly.
While the scope of work varies, all product-oriented teams share fundamental principles that drive alignment, agility, and accountability.
Every team operates against a proactive, long-term roadmap that ensures continuous improvement rather than reactive project execution. Whether delivering a customer-facing experience, maintaining a data platform, or supporting enterprise technology services, teams work with a strategic view of how their domain evolves.
Each team balances two complementary focuses: working on the business, which drives innovation and efficiency, and working in the business, which ensures the successful delivery of day-to-day operational needs. This ensures that even services teams, which spend more time on operational stability, are still evolving their capabilities rather than just maintaining them.
Regardless of the type of product a team supports, they all operate with common ways of working, typically inspired by agile methodologies. Structured sprints, iterative delivery, and continuous alignment with business stakeholders ensure that teams remain responsive and adaptable while maintaining consistency across the enterprise.
If you’re leading the shift to a product operating model, anticipating these nuances and addressing concerns early will be essential. A key first step is clarifying roles and responsibilities so that technology service teams understand their continued relevance and how their work aligns with the new model.
Defining success metrics tailored to each team type ensures that performance is measured in a way that reflects their contributions. Adoption, uptime, and customer experience are all critical, but the specific emphasis will vary based on whether a team is customer-facing, platform-focused, or service-oriented.
Encouraging cross-team collaboration is equally important. A strong product operating model is not about isolating teams but about fostering an ecosystem where platform teams, enterprise application teams, and product teams work in tandem. Aligning their priorities and reinforcing shared ways of working will drive efficiency and long-term success.
The transition to a product operating model isn’t just for digital-first teams—it’s for all of technology. Whether your team is building customer-facing products, enabling developers with reusable platforms, or maintaining critical enterprise applications, the fundamental principles of product thinking apply universally.
by At first glance, the shift toward product thinking may seem tailor-made for teams working on customer-facing digital products, like mobile apps or eCommerce experiences, where new features are envisioned in lockstep with business units that have P&L responsibility. But what about teams maintaining enterprise applications like SAP and Salesforce? Or those responsible for shared APIs, IT Ops, and core platforms, which serve multiple product teams rather than direct customers?
CIO turned VC Brian Hoyt draws on his experience prepping companies for IPO and other liquidity events, including his own, to outline a playbook for crossing the start-up to scale-up chasm.
This article was originally published on CIO.com by Michael Bertha, Partner at Metis Strategy and Duke Dyksterhouse, Senior Associate at Metis Strategy
Suppose you lead IT at a VC-backed startup. It just crossed $100M in revenue and is approaching a major liquidity event, such as an IPO. It’s exciting stuff. But as you speak with an expanding cadre of lawyers, accountants, and bankers, you start to appreciate what such an event means for your department.
You start to see the cracks in its foundation. You see the data by which Wall Street will judge your business is scattered across the company, stored and formatted unsystematically. You see the systems that must be repaired (or built) if the firm is to comply with SOX. You even acknowledge that IT has been kept afloat by managed service providers and fractional employees. All of this, you realize, must change. You’ve reached a tipping point at which your IT capabilities must be formalized, but you don’t know where to start.
Fortunately, Brian Hoyt does — and he’s been there, having served as CIO of real-time 3D content creator Unity Technologies, for which he prepared the IT department for IPO in 2020. Today he serves as partner and chief operating officer of Parkway Venture Capital, which invests in software and AI/ML companies across various sectors. He helps the firm’s portfolio companies tackle the intricacies of crossing the start-up to scale-up chasm.
Here, Hoyt shares what he’s learned from scaling IT in rapid-growth companies, both as a CIO and an investor, and what should be considered by digital and technology leaders whose firms are heading for major liquidity events — how they might structure their departments so that the company can weather that liquidity milestone and the S-curves in the years that follow.
There are no exact thresholds for formalizing your IT capabilities, including hiring or promoting a CIO, says Hoyt, but there is one important sign: talk among your colleagues about redoing the company’s ERP system.
“I think people usually go QuickBooks, NetSuite, then onto something else, or they redo NetSuite. And often your accounting team had to implement NetSuite without IT’s support,” he says. “It works for their purposes for the time, but when it needs to be refashioned so that it can scale, that’s the time to bring in someone with some seniority, someone who’s been through it, because it’s really hard.”
Why does an ERP redo or implementation present such a great opportunity to evolve your IT organization? A couple of reasons. First because, as Hoyt observes, ERP implementations are notoriously difficult. Few leaders will volunteer to drive the work and often it will fall to the accounting team. “In many cases that won’t work out,” he says, “because the accounting team must devote themselves to their principal work, which is critical, and because they have lives and implementing ERP software sucks.”
But also, ERP systems rely heavily on IT-supported capabilities, so any work necessary to implement one will likely involve your team anyway. You might as well be the one to command that work; as a tech leader, you’re especially well suited to it, and doing so will give you reason to acquire resources that lend themselves to causes beyond those related to ERP. In other words, remodeling your ERP can afford the chance to remodel your department — to effectively say, “If we’re going to do this, I’ll need the following.”
Of course, the ERP sign is only a rough guide, says Hoyt. The right time depends on your business and industry; the more regulated it is, the sooner you should start. He uses selling into enterprise software as an example. “If you’re going through a lot of security reviews, plan on hiring a CIO earlier. My first question [to entrepreneurs in that space] is: How are you getting through security reviews? And they all groan. The people who have a clear answer are going to do better.”
As it happens, regulation — or compliance — is another area for which you’ll need to hire or promote a leader. Although Hoyt stresses he isn’t one to “insist that you hire from outside,” here you likely need to.
“You need someone who knows the territory, who knows Sarbanes-Oxley and the language of the auditor and preferably someone who’s even worked at your auditor’s firm and can speak their language and prepare everything,” he says. “Otherwise [the auditors] will grind you into a fine powder because they have an endless bench of people to schedule meetings and ask that processes be explained.”
There are plenty of candidates for this role, Hoyt says, but you might need to look outside the box. “They might not be in a job called ‘Head of Compliance.’ It might be ‘IT auditor,’ and they’re tired of flying between Nebraska and New York every week. And I think this has been a huge part of what I’ve done in the past, is finding this person.”
You’ll also need someone to lead infrastructure and ops, which rarely gets the attention it deserves when the firm’s still young and focused on core products and the viability of its business model. Often by the time the firm’s leaders start talking about going public or agreeing to sell, the firm’s foundational technologies may be in need of a closer look. A major piece of this domain is security, which Hoyt says can roll up to the infrastructure and ops lead at first but must eventually become a separate function.
“As your firm grows and starts looking to go public and becomes a bigger topic, you become a bigger target,” he says. “Some attacks from sophisticated bad actors are unavoidable, but you at least want to ensure that you don’t leave yourself vulnerable to avoidable slips.”
Finally, you need someone to lead your financial and business systems. “I love accountants interested in systems,” says Hoyt. “They’re often perfect to lead this area, and a lot of modern CIOs need technically minded leaders that they can trust to know whether a system is out of whack or a piece of work can be executed.”
Why is this leader so vital? Largely, Hoyt says, because of the projects you’ll have to undertake to prepare for your liquidity event.
Hoyt suggests that CIOs can learn much about the projects they’ll have to drive for a liquidity event from the focus of Wall Street earnings calls.
“They’re all about financial predictability and accuracy. Your firm’s viability as a financial asset largely comes down to investors asking, ‘Can we trust this company’s numbers? Will they be delivered on time?’ And if you get your numbers wrong, or they’re late, you can’t fix things by saying, ‘Well, you know, my IT person didn’t come through,’” he says. “And you can’t continue to spend 90 minutes in exec meetings arguing about whether the data you’re all looking at is right or how it’s defined. If those conversations are still going on, then you know there’s work to be done and that you need to start it as soon as possible.”
Getting the numbers right may sound simple, but it’s grueling work, Hoyt says, starting with getting your data right at the source.
“You have to stop fixing problems in the data layer, relying on data scientists to cobble together the numbers you need. And if continuing that approach is advocated by the executives you work with, if it’s considered ‘good enough,’ quit,” he says. “Getting the numbers right at the source requires that you straighten out not only the systems that hold the data, all those pipelines of information, but also the processes whereby that data is captured and managed. No tool will ever entirely erase the friction of getting people to enter their data in a CRM.”
The second piece to getting the numbers right comes at the end: closing the books. While this process is a near ubiquitous struggle for all growing companies, Hoyt offers two points of optimism. “First,” he explains, “many teams struggle to close the books simply because the company hasn’t invested in the proper tools. They’ve kicked the can down the street. And second, you have a clear metric of improvement: the number of days taken to close.” Hoyt suggests investing in the proper tools and then trying to shave the days-to-close each quarter.
Get your numbers right, secure your company, bring it into compliance, and iron out your ops and infrastructure. Do these things and you’re a long way toward being ready for a major liquidity event — or just your company’s next chapter.
Hoyt is so knowledgeable in this area that he answered virtually every one of our questions without hesitating. So it should say a lot that, when asked what one bit of advice he’d leave with CIOs preparing for a liquidity event, he pondered his answer for what seemed like 10 interminable seconds.
“Make sure you have the full support of the top officers — the CEO and CFO, or COO. It’s hard work. And to some extent you’re going to have to make people’s lives harder, so there’s going to be friction,” Hoyt says. “The only way you’re going to overcome it is if you have top-down alignment. As time goes on, more CIOs are reporting to CFOs or COOs or CEOs. But in some firms, the CIO still reports to someone farther down the food chain. That won’t cut it in a firm preparing for an IPO.”
And that’s good news for IT leaders looking to take a step forward with their careers at startups and beyond, he adds.
“CIOs hold a unique position,” says Hoyt. “They can see every part of the company. They see the challenges regarding real estate and ERP and so on. That purview has to be recognized and respected if a firm is serious about playing in the big leagues.”
In transforming your IT workforce, modeling its to-be composition is a necessary and smart first step, but it represents only the tip of the iceberg. Here’s how to pressure-test your model against the realities of execution.
This article was originally published on CIO.com by Michael Bertha, Partner at Metis Strategy and Ishan Prakash, Manager at Metis Strategy
In today’s ever-expanding digital landscape, in which many IT teams operate across geographies, it’s no secret that your ability to leverage technology to its fullest depends crucially on your workforce composition: on how your resources are allocated across various sourcing models, namely, FTEs, onshore, nearshore and offshore. As technology becomes ever more important to strategy, IT leaders are reconsidering their workforce compositions. Where they once optimized predominantly for cost, they’re now weighing that one variable more carefully against many others, including productivity, digital maturity, and the development of longstanding capabilities.
And though modeling the composition of a to-be workforce is a necessary and smart first step, it represents only the tip of the iceberg. In other words, it’s unrealistic to redeploy a role as part of a different sourcing model and expect instant productivity gains. Countless variables must be considered: skillset alignment and maturity, time zone differences, and ways of working (both within a team and across the organization), and so on.
Acknowledging these challenges and complexities, how can one pressure-test their spreadsheet exercise against the realities of execution? Drawing from our collaborations with several Fortune 500 clients on this topic, we suggest an archetype-based approach, one that, when executed well, will allow you to charge ahead with implementing your to-be workforce composition, and with the confidence that it reflects the needs of your organization.
By shifting the composition of your workforce, you are bound to affect certain functions, capabilities, or products. Begin by understanding those entities’ remit and ways of working. Are they developing novel products and services? Configuring a package solution? What key technologies are they using? What skills will enable operations in the new model? Are they working in agile? If so, what flavor do they employ?
As an example, consider the case of a global retail client. In assessing the demand profile of the team that oversees their fulfillment capability, the client examined their inventory management solution, a niche one, and determined that, even though the company might benefit by bringing the solution’s support team nearshore, the right skills would be hard to find in the short run.
Cataloging the answers to these questions provides a fact base that allows you to understand what capabilities, roles, and skills will be needed to support demand. And perhaps equally important, it allows you to understand which of those capabilities are fungible across sourcing models, and which are, at least in the short run, tied to specific locations or vendors.
After constructing a demand profile for each function, look across those profiles. Reconcile and rationalize them. And make sure the various types of demand will be supported by creating a master set of archetypes.
What’s an archetype? In this context, archetypes encompass the roles, responsibilities, and geographies that constitute a specific capability and that are required to support a certain type of demand.
As an example, consider the archetypical teams found at one of our global retail clients. For one, they have an infrastructure delivery team archetype, which consists of a nearshore engineering delivery manager, a scrum team, and both a nearshore and offshore delivery team (i.e., developers), the latter supplementing the former with overnight or follow-the-sun support. They also have single or multi-capability delivery teams that work on, among other things, innovation and product development, and operations and maintenance. As you can imagine, the archetype after which these teams are modeled varies based on the demand profiles they are constructed to satisfy. While every organization is different, we often challenge our clients to limit themselves to six archetypes.
By undertaking this exercise, you not only confirm that your teams are structured such that they can both support demand and satisfy the objectives of the workforce shift; you create a vehicle for scale and standardization in what is likely to be a multi-vendor, multi-geography workforce.
Having established a master set of archetypes, it’s crucial to apply them to each function’s to-be workforce composition. Doing so will reveal discrepancies between those archetypes needed to satisfy demand and those targeted for the to-be workforce compositions, which may have been painted with broad strokes in a top-down exercise that gave little consideration to execution.
By applying the archetypes to your to-be model, you will quickly see where your current workforce easily ports into the new model, and where there are gaps that must be closed through some combination of reskilling, recruiting, and partner sourcing. The time it takes to execute these tactics will inform the speed and sequencing of implementation.
Here you can also take stock of the various ways of working practiced by the different capabilities or functions. If those capabilities and functions work similarly then perhaps it will suffice, as responsibilities change in the new model, to simply recalibrate planning and execution processes. If they work quite differently, however, then a major change will likely complicate both their work and the effort to shift the workforce composition. The discrepancy may indeed merit a broader reset as you move toward the to-be model. It is also at this point that more attention tends to be given to an organization’s horizontal capabilities. One such capability that often surfaces is Knowledge Management: how do we ensure that in changing or relocating a resource, we don’t lose critical institutional knowledge?
By the end of this exercise, you will have effectively pressure-tested your to-be model. You will have uncovered a clear set of gaps that, when accounted for in your roadmap, will help you avoid surprises as you move towards the to-be workforce model. You will also have created a set of archetypes that transcend the seams of your workforce ecosystem and bring harmony and scale to your multi-vendor, multi-geography workforce.
If your organization is anything like those of our clients,’ you will have realized that a shift in global workforce composition, what may initially feel like a lift and shift of resources, is akin to engineering a skyscraper: structural integrity, precision, and attention to detail are paramount to ensuring that the building can withstand any pressures and function according to the needs of its occupiers and stakeholders.
Walgreens’ Stephen Ma shares why fewer architects, with wider domain expertise, may close the gap between EA’s ethos and its perceived value proposition.
Skim recent articles about enterprise architecture (EA) and you’ll notice a contradiction. Of them, plenty suggest that, unless a company develops a strong EA muscle, it will limit itself. Yet just as many seem to question the function’s value, or spotlight material that does. A recent report from Forrester, for example, opens: “[While] enterprise architecture remains a critical capability … many digital and IT professionals view enterprise architecture as a roadblock that adds no real value.”
All this contradiction suggests that EA, as a function, may be suffering an identity crisis, but Stephen Ma — acting chief architect at Walgreens — is not about it.
Ma doesn’t object from a place of defensiveness — he knows the function’s value. But he’s frustrated that the discipline’s value hasn’t been communicated as well as it should be, a grave issue in today’s business climate, in which every role of every function is under scrutiny. He also thinks the solution is straightforward.
“We need a full-stack architect,” he says.
That’s right: According to Ma, the solution to EA’s identity crisis is fewer architects, but ones with the ability to traverse multiple architectural domains.
To understand what makes an architect “full stack,” we first need to define EA. Per Gartner:
“Enterprise architecture (EA) is a discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve targeted business outcomes that capitalize on relevant business disruptions.”
Not all this work gets done by architects of the same type. By Ma’s count, there are at least four major architect types: Business, Solution, Enterprise, and Technical. Each works across at least two of six major domains of expertise: Business, Product, Design, Engineering, Delivery, and Support. None of them works across all six.
And herein lies the problem, says Ma: When business stakeholders seek to understand EA’s value proposition, or even check the status of a project, they may get different answers depending on whom they ask. It’s the three-blind-men-describing-an-elephant problem: The man who feels the tail describes an animal very different from the one described by the man feeling the abdomen, or by the one feeling the ears and tusks. Though the variety in their descriptions may reflect the function’s comprehensiveness, to the uneducated executive, it sounds like misalignment. That executive feels that, to get a complete picture, he or she must piece it together him or herself.
As Ma sees it, this perception has never been more damning than it is today.
“A lot of people, during COVID, really thought COVID was going to live with us for the foreseeable future, so companies made big digital bets on how people work, how customers interact … and they over-hired,” he explains.
Among these digital bets was greater investment in technological functions believed to critically enable strategy and scale in a remote world — functions like enterprise architecture. Ma recalls how difficult it was to attract talent to CVS, where he was leading architecture at the time.
“I would put a job description out there for a really quality principal architect or director position, and I would get one good resume maybe every three weeks,” he says. “It took me six months to even think about finding somebody good.”
Of course, in the end, many of those bets didn’t pan out. The pandemic ended, many customers returned to their usual patterns of behavior, and about a year ago, companies began revisiting hiring decisions they made under different pretenses, asking, “What exactly does this role do?”
And now, with technologies such as AI emerging, they’re asking twice as emphatically. Ma warns all architects that they need to be able to answer this question clearly, consistently, and persuasively.
“I’ve actually heard fellow architects say, in describing their role, that they’re ‘marriage counselors.’ Relationship-building is very important, but it alone is no longer enough. Architects have to know what they are talking about at a deep technical level,” he says.
To solve this problem, Ma sees the emergence of a full-stack architect who can describe the whole elephant — and enhance EA’s service delivery model by several means.
First, the full-stack architect could ensure the function’s other architects are indeed aligned, not only among themselves, but with stakeholders from both the business and engineering.
That last bit shouldn’t be overlooked, Ma says. While much attention gets paid to the notion that architects should be able to work fluently with the business, they should, in fact, work just as fluently with Engineering, meaning that whoever steps into the role should wield deep technical expertise, an attribute vital to earning the respect of engineers, and one that more traditional enterprise architects lack.
For both types of stakeholders, then, the full-stack architect could serve as a single point of contact. Less “telephone,” as it were. And it could clarify the value proposition of EA as a singular function — and with respect to the business it serves. Finally, the role would probably make a few other architects unnecessary, or at least allow them to concentrate more fully on their respective principal responsibilities. No longer would they have to coordinate their peers.
Ma’s inspiration for the role finds its origin in the full-stack engineer, as Ma sees EA today evolving similarly to how software engineering evolved about 15 years ago. During that time, as social media and e-commerce exploded, so too did the variety of software engineers holding the seams together. Those engineers gradually sorted themselves into realms of expertise — front-end, back-end, data layer, and so on — and ultimately came to be coordinated by the full-stack engineer, now quite common in mature organizations, and expected to become only more so over the next decade.
Ma sees this role as analogous to the full-stack architect: “You can’t really have one person, engineer or otherwise, who’s truly a full-blown expert up and down the stack — I’m not suggesting this is a magic bullet — but the idea here is, let’s have full-stack architects who cover all areas from both a business and technical perspective.”
For some readers, this may beg the question: How would the full-stack architect differ from a product owner? Do they both not link the business and the digital execution? They do, but with different priorities. Product owners, explains Ma, even technical ones, tend to never get sufficiently deep into the weeds of the technology itself, always concerned first with the product. Having worked in organizations that leaned on such roles, Ma has never seen it work.
“Maybe it could if your company is clear about what it does and which roles have exactly which responsibilities, but most are not and don’t. You need a role that can help the in-between, that can be the glue holding together some of the areas that fall under several verticals, and who can be the person that anyone — engineers or businesspeople — can go to when they have a need that concerns both the business and the technology teams,” he says.
Another important justification that Ma offers for such a role is that the problem solved by architects is here to stay, even as advanced technologies enter the equation.
“It’s part of the reason I love this space,” he says. “What’s under it is so many different technology domains — integration, data, APIs, and so on — but also multiple business prongs and industries. There is so much to learn.”
The same can be said for most companies today, as they branch out into new opportunities, often by way of digital transformation, he adds.
“Consider Walgreens, people usually think of our pharmacy, but we also have photo, healthcare clinics, supply chain, and many more functions,” Ma says. “You’re always going to need someone who can bridge the gap between business and technology. You’ll always need someone who underpins it all.”
Underestimating the importance of this role could make or break your operating model transformation: here’s how to think about sourcing the role that will only increase in importance.
This article was originally published on CIO.com by Michael Bertha, Partner at Metis Strategy and Kira Kessel, Associate at Metis Strategy
You’ve seen the virtues of transforming from a project to a product operating model: value-driven work, delivered by dedicated teams rather than through projects led by disparate team members.
But as you embark on this transformation, you’ll have to remember one thing: you can’t do it without a product owner. The strategist, the technical expert, the business savvy leader—those with all three commonly called unicorns, or rock stars—is a person not easy to find.
Product owners are the linchpin of the product operating model; on product teams, a bad engineer is one bad apple, but a bad PO can sour the whole batch. No one else has the end-to-end accountability for a product like the product owner does. No one else so consistently represents customer interests, pushes engineers to adopt DevOps and Agile methodologies, and corrals individuals to execute against a roadmap. This is a leader who thinks of technical features in one conversation and business strategy in the next. The unicorn, if not sourced with proper due diligence, will be viewed only as a creature in fairy tales.
In a traditional project model, a leader is judged based on how well they react to requests and executes on them. In a product model, however, a good product owner anticipates the customer needs and responds to them by prioritizing items on a roadmap based on the capacity of a product team.
Product owners move you from reactive to proactive.
Adopting the product model is no meager mind-shift. Broadly speaking, you have two main options: hiring or upskilling.
You might hire for either of two reasons. The first is that you may not have the luxury of time and mistakes. This is largely a matter of two things: culture and industry.
Let’s start with culture. Ask the following of your company: Is learning tolerated? Is training available? Are there resources you can use to help establish the person in their role? Is there strong leadership and mentorship? Without these variables at play it will be difficult to develop someone internally. You might need someone who has the core PO competencies and fits your culture, someone who perhaps already has the leadership chops you’re lacking—a necessary hire.
Then there’s industry. Also unable to afford time or mistakes are those industries that are heavily regulated, scrutinized by agencies and governments, or uniquely depended upon by their customers. If, for example, you work in medical, military, aviation, and so on, you may not want to risk upskilling when you need someone who can navigate complexities beyond just those inherent to a product owner’s role. These product owners will have to consider certain variables—safety, cybersecurity, geopolitical factors, and many others—that require extra attention when representing the voice of the customer.
Say you’re a technology executive at a biopharma company. Your product owner will not only need to drive innovation—putting the most promising features at the top of the backlog—but will also need to do this while adhering to regulatory constraints. For Shobie Ramakrishnan, Chief Digital and Technology Officer at GlaxoSmithKline, this looks like balancing core values like “accountable for impact” with the pursuit of AI/ML technologies to “supercharge” R&D and clinical trials.
Luxury and time, of course, is only one of the reasons you might hire. The other is that you want a fresh perspective. In particular, someone who offers a point of view you can’t train. Usually that someone comes with a mixed bag of experience: a background in product, engineering, marketing, and finance are most common. What matters is that they offer something new to your company. A leader like this may disrupt the status quo, bring innovation, and offer new ways of thinking about the same problem. They may even serve as a catalyst for change beyond your recent move to the product model.
But could you not solve these issues—the constraints of luxury and time and the desire for a fresh perspective—by outsourcing? Your contractor may not cost as much, but you may face bigger drawbacks. A contractor who doesn’t stick around will take with them the skills and experience you want an employee to share with colleagues so that expertise, new ideas, and growth of the company reinforce one another from within.
In contrast, when you retain someone full time, especially a product owner, you retain institutional knowledge, which is especially valuable when it concerns strategic areas like GenAI, data, cyber and other innovation—areas of central concern to the product owner. A good example of this comes from Zurich North America’s COO Berry Perkins, who has made it part of IT strategy to keep this type of knowledge in-house. Of course, that’s not the only part of the strategy—it also involved the establishment of nearshore competency centers that will depend on Zurich’s employees acquiring new skills and embracing new processes and technologies. Which brings us to upskilling.
You may have a unicorn in your backyard without even knowing it.
What can distract you from that realization? Budget. If it prevents you from hiring, then you may next consider whether you have the funds, and the bandwidth, to pursue training your soon-to-be product owner.
Investing in your training muscle—developing a training capability, establishing career coaching, and encouraging growth from within in other forms and fashions—could do more than just produce the perfect product owner. It will signal to your employees that you want them to stay, that their contributions matter, and that there is space for them to grow internally. Retention could soar, innovation may spike, and revenue would, inevitably, grow.
If training isn’t on the agenda, you may decide to pursue upskilling simply because your employees hold something valuable already: their relationships and their institutional knowledge. The high-performing product owner will have already built relationships with their colleagues, will know the dynamics that exist between teams, will understand the technologies used, and will be better equipped to align IT and business stakeholders. Most importantly, they will have established trust.
Perhaps not even trust is the most important thing. What could be? Institutional knowledge, which, as we’ve seen, an existing employee will already have. They will know the tools, know the processes (which they’ve seen are convoluted at times), and know the customers of the company they are serving (and can speak to the company’s competitive differentiation, not just industry norms). Best of all, they know the product—its thorns, buds, and roses.
Believing in the value of the product operating model is one thing. It’s another to embrace the transformation from project to product with eyes wide open. You should acknowledge the challenges you will encounter, most notably that this one role could make or break the transformation. So before you’re too far into the journey, remind yourself: if you don’t know who your product owner is, at least understand what will dictate whether you hire, contract, or upskill. Better to figure it out now, not later.
Company-first CIO Krzysztof Soltan and his team helped transform the construction-aggregates giant with a focus on digitizing operations, modernizing infrastructure, and overhauling how IT goes about its business.
This article was originally published on CIO.com by Michael Bertha, Partner at Metis Strategy and Chris Boyd, Manager at Metis Strategy
In a recent “all-hands” meeting, Krzysztof Soltan, CIO of Vulcan Materials, announced his IT organization would continue its “laser focus on digital transformation.”
Digital technology, he explained, would remain a central focus of the construction-aggregates industry and would underpin customer-grade experiences increasingly expected from industry leaders. Vulcan, based in Birmingham, Ala., is the nation’s largest construction aggregates company, producing materials such as crushed stone, sand, and gravel, with strategic downstream assets like asphalt and ready-mixed in select markets. Soltan, previously a tech leader at Johnson Controls, ABB, and GE, became the company’s first CIO just two years ago and is at the forefront of the company’s digital transformation efforts.
Soltan and his fellow leaders attribute Vulcan’s success to many things, but chief among them is the company’s attitude toward key activities like operating and selling — “The Vulcan Way,” as it is widely referred to within the company. This orienting force has become so strong that, to Soltan and his team, it seemed only right that they should rethink IT in terms of how it might amplify the approach. As Soltan explains: “If we were going to keep up with the pace of change in the industry, IT would have to be recalibrated.”
Here, Soltan and his IT leadership team share the story behind those efforts. They highlight the mindset and approach necessary to leverage new technologies to best compete in the digital age.
As Soltan’s IT leadership team explains, Vulcan’s digital transformation turned a corner with the advent of the Vulcan Way of Selling, an enterprise-wide initiative that, through technology, aimed to turn the company’s highly manual relationship-based sales model on its head. And so it did.
Since the initiative’s launch in 2017, Vulcan has deployed myriad proprietary technology solutions that serve up real-time market insights, thereby improving experiences for sales reps, customers, and the truckers responsible for transporting goods to job sites. For sales reps, these improvements show up as more time spent talking about solutions with customers, and less time on administrative work like quoting. For customers, real-time location-tracking of materials shipment translates to better labor planning. For truckers, a seamless, paperless experience when picking up materials at a Vulcan quarry means faster delivery.
As Vulcan SVP Jerry Perkins put it at the company’s 2022 investor day, “Time is money in the construction and trucking industry, and these tools make our truckers and customers much more efficient and productive.”
The success of the Vulcan Way of Selling brought the company to an inflection point. Enterprise-wide, tech-enabled transformation programs would no longer be one-off events; instead, they were destined to become fixtures in Vulcan’s pursuit for continuous improvement.
Enter Soltan. After learning the business and getting acclimated with the effort to integrate US Concrete, which the company had recently acquired, Soltan got to work charting IT’s path forward. “Between the US Concrete acquisition and other major initiatives, we hadn’t taken a step back in awhile to reflect on how we were managing our own shop,” Soltan says, noting this isn’t unusual for companies during periods of growth.
The path to cementing Vulcan IT’s value proposition, says Soltan, would be two-fold: Invest continuously in enabling business-driven initiatives, and modernize how they manage the business of IT.
As just one example, the company has commenced VulcanX, an initiative that extends the Vulcan Way of Selling by providing best-in-class tools to the company’s Sales teams to help them win more business and deliver better experiences to customers, in the form of seamless and secure interactions. These efficiencies, the company hopes, will drive more quotes and, subsequently, higher quote-to-order conversions, all while allowing the team to spend less time on administrative tasks.
Just as important is the technical foundation on which Vulcan operates its plants. And so the company has launched another initiative in partnership with its business units to modernize the organization’s technical infrastructure, including improving the speed, connectivity, and mobility of its networks in service of Vulcan’s 10,000+ employees — qualities that will become only more vital as the company multiplies its digital capabilities.
“One reality of our business is that we have to enable modern day technology in the rugged, remote locations that are home to our plants and quarries,” says Soltan. “VulcanX enables scale and mobility in the plant with cloud-based solutions, and our modernized networks will improve our ability to capture data and to quickly drive insights for the folks running our operations.”
Vulcan’s employees can leverage digital capabilities in the field only to the extent that the company’s IT and OT systems are integrated. This reality — understood by Vulcan’s business unit leaders as well as anyone — has ultimately stood to justify, incentivize, and propel the company’s transformation.
A great deal of Vulcan’s success in managing the business of IT can be traced back to the department’s operating model. “The capabilities you deliver within IT the roles and responsibilities, and the ways of working — getting these things right — creates a solid foundation for execution,” Soltan says. To Vulcan’s leaders, it made sense, then, that the operating model should be among the first things they strove to modernize.
First, there was talent strategy — how the company would recruit and train. Of particular concern was the department’s IT career paths, which stood to be refreshed. As Soltan recalls, “We needed our paths to be more indicative of the work we’re doing. This not only helps us attract new talent but allows our team to feel confident they are adding modern skills to their toolkits.”
To this end, Vulcan leaders did two things. First, they developed a new set of career paths, including specific tracks for product management, DevOps, Data Engineering, and other sets of skills that, as Vulcan advances, will become indispensable. Second, the leaders expanded its talent pool by opening a second hub in Dallas, home to Vulcan’s US Concrete acquisition, and the fourth largest metropolitan area in the United States.
The second facet concerned projects, which experienced high demand. As Soltan explains, when digitally transforming at the pace Vulcan has, “priorities change daily, and without rigorous governance processes, it’s nearly impossible to have visibility into your IT investment portfolio.”
To rein in demand, and ensure resources were allocated impactfully, Vulcan formalized its IT Project Management Office (PMO). “The goal is to manage IT like a business,” says Soltan. “That means being clear about investment criteria for IT projects and establishing expectations for project execution that allow us to monitor value capture.”
For Vulcan, each new project introduces new applications and integration patterns into the technical estate. To ensure these can be properly absorbed, Vulcan also invested in maturing its enterprise architecture muscle. “Standards around technologies, integration patterns, and security are becoming more important,” says Soltan.
“Architecture ensures that new solutions do not render old ones redundant and that we construct things in a manner conducive to easily capturing and integrating data,” he explains, noting this will only become more important as IT/OT convergence accelerates to enable capabilities such as predictive maintenance in the plants.
For CIOs in similar sectors just starting out on digital journeys, the prospect can be unsettling, especially in light of recent technological changes — the AI craze, the pace at which IT and OT are converging — not to mention the list of demands from the business. And still, as Soltan says, one thing is certain: Technology will increasingly enable you to compete and differentiate yourself.
So if your company is like Vulcan Materials, if it has climbed to great heights despite preceding the dawn of digital, Soltan suggests you get started: “Your business leaders are smart. They know the importance of technology and of modernizing IT to compete. They have your back. So look honestly at where you are, rip off the band-aid, and start moving, piece by piece, towards your future state.”
Zurich North America COO Barry Perkins shares how tech chiefs can repatriate skills and hone digital prowess by rethinking the onshore, nearshore, and offshore composition of their global workforce.
Composing a workforce is like playing chess. When it’s done well, every choice is calculated, made mindfully of both its short- and long-run impacts, and of the delicate balance in which it must hold certain key variables — cost, productivity, digital maturity, and the potential to build capabilities that last.
In striking this balance, digital and technology leaders have long optimized for cost, but so rapidly is business evolving that many of them are reconsidering that approach. Among such leaders is Barry Perkins.
From 2011 to 2023, Perkins led technology in various senior-level roles for global property and casualty group Zurich Insurance. Then, in September 2023, he became COO of the company’s North American outfit (ZNA), revenues of which exceeded $22 billion that year. Atop his tech-related responsibilities, Perkins inherited responsibility for ZNA’s operational functions, such as premium audit and call-centers, and for thousands of global IT workers. Of the latter, 70% to 80% were supplied by strategic partners.
“In many cases,” explains Perkins, “we’ve become supplier-managers. And while that can be good from a cost standpoint, it’s become a limiting factor to increasing our digital maturity.”
As Perkins explains, an IT organization will constrain itself if it depends too heavily on suppliers. It will struggle to act autonomously, meet evolving priorities, and innovate. It might even suffer atrophy in critical functions such as recruiting and career development, as the employees overseeing those functions are taxed increasingly by the burden of managing suppliers.
So how do you forge a different path? Perkins advises IT leaders to adopt three principles to strike the right balance between cost, productivity, digital maturity, and the means to build long-term capabilities. These principles, Perkins contends, can catalyze digital transformation when prioritized across the enterprise.
First, says Perkins, IT leaders should “differentiate very carefully the areas for which you’re going to focus on maturing your digital capabilities, and what they mean to the organization.”
Having aligned on this, you can examine your workforce to ascertain whether your onshore, offshore, and nearshore operations are optimized for cost, productivity, and digital maturity, among other variables.
Before he became the COO of ZNA, Perkins served in Europe as Zurich’s COO of group technology and operations, and as head of the company’s business technology centers. In this latter capacity, he oversaw the company’s nearshore competency centers, which would later serve as a blueprint for the one he would proactively establish in Mexico after coming to ZNA. Aside from sharing time zones with America, this center would cost less than US-based resources and provide access to more diverse talent.
Perkins warns CIOs not to underestimate the effort and complexity of building a nearshore capability. It took his team “two years just to get the basics of the center and management set up with a core set of 80 to 100 people.” After laying the foundation, Perkins filled roles by drawing on both ZNA’s internal recruiting muscle, and on vendors through a model of build, operate, and transfer. Vendors provided resources with specialized or rare skills. Internal recruiting handled the rest.
Perkins explains that there’s a benefit to placing key functions such as developers and strategic decision-makers in similar time zones. Doing so enhances collaboration and cuts response times relative to an offshore outsourcing model in India, for example.
With a nearshore operation in place, as well as offshore and onshore ones, Perkins and his teams could pull from the full spectrum sourcing models. His team was ready to start moving chess pieces.
According to Perkins, one key to controlling your digital destiny is to bring your most strategic roles onshore. “You can reclaim autonomy over your key digital initiatives, build internal capabilities, and repatriate institutional knowledge all by reducing dependencies on suppliers.”
As for which roles should be upskilled and hired full-time, Perkins swears by the mnemonic “ABC”: artificial intelligence, big data, cybersecurity. Generally, he says, business stakeholders understand how important these capabilities are, and are thus more likely to invest what’s necessary to build them internally. “Given their importance in protecting as well as transforming the organization, these are not areas they would want to outsource,” Perkins says.
Transitioning individuals in house, however, typically raises labor costs, and as Perkins notes, that proposition will likely cause a few stakeholders to raise an eyebrow, despite their recognizing the strategic importance of digital operations.
“When your leadership has gotten accustomed to the highly outsourced workforce composition,” explains Perkins, “there are challenges in shifting the cost profile.” Therefore, he says, it’s imperative to have a strong business case and predefined criteria for shifting your resources. You’ll need them to justify such a move.
Finally, Perkins underscores the importance of including your peers in your workforce transformation journey. Whether you’re pitching for resources to be shifted to a nearshore captive, or for cloud to be more fully adopted, Perkins insists that the message should be delivered in business terminology, and that it should highlight the value proposition.
“Cost advantages, accelerating speed to market, and making better decisions will resonate with your peers,” he explains. “Reserve the three-letter technical acronyms for your IT colleagues.”
Equally if not more important to bring along on the journey is the IT workforce. The priority is to help “employees not just understand their responsibilities today but rather encourage them to actively participate in setting up a future roadmap,” Perkins says. By harmonizing mindset, skillset, and toolset, you’ll equip your employees to manage constantly evolving technology and innovation.
The thought of re-composing a workforce, uncomfortable as it can be, can paralyze even the most seasoned CIO. But given the pace of digital change, it can be even more detrimental to avoid the work and to push forward with a cost-above-all mindset.
Today, every company is a technology company, and thus, as Perkins suggests, you should get comfortable with being uncomfortable.
“Shifting your workforce composition is a major operational and cultural change,” says Perkins. “It’s not for the faint of heart, but it’s necessary if you want to position yourself for the future.”
Associa CIO Andrew Brock expanded his C-suite mandate by parlaying his IT purview to helm proptech spinoff HOAM Ventures. Here’s his advice on doing the same.
This article was originally published on CIO.com by Michael Bertha, Partner at Metis Strategy
Early in his career, Andrew Brock was told by a mentor that, to reach the C-suite, you have to take assignments across the various drivers of a P&L: marketing, operations, information technology, and so on.
At the time, Brock had held finance-related roles of increasing responsibility at household brands such as Kraft and PepsiCo at the time, and the advice piqued in Brock a curiosity that has since marked his career. It led him to accumulate cross-functional experiences that eventually landed him at Associa, which, serving 7.5 million homeowners globally, is the world’s largest residential property management company.
In rather short order, Brock was tapped to lead the launch of Associa’s first client shared-service center, and the success of that initiative propelled him to the perch of CIO, where he inherited corporate IT and the remnants of a forgotten software development group that came via a previous acquisition. Again, his curiosity was piqued.
“I wondered if we could use the development group to start building our own products,” Brock explains. “We were paying a lot of third parties to provide digital services to our clients.”
As it turned out, they could, in fact, build their own products. Soon after repurposing the development group, Brock and that team launched the company’s first digital product: a solution through which residents could pay their HOA fees digitally. This solution, along with other early products the team developed, significantly reduced costs, inspiring Brock to consider whether these products might be commercially viable on the open market.
The opportunity, as Brock explained, was that the market was fragmented. Associa, as large as it was, owned less than 10% of the residential property management market, even as the market leader. This intense fragmentation meant fewer barriers to entry for entities looking to introduce new solutions, so Brock and his team determined that “if we built a product that worked for us, it could also work for the open market.” And they were right. As these products built a client base and a sales team was mobilized, it became easier to cross-sell more digital services, and by doing so, they created for Associa not only a new organic revenue stream, but a platform by which they could scale their acquisition growth strategy — which, in the era of prop-tech, focused increasingly on digital services.
Once the operation was earning profits and boosting EBITDA, Associa’s leadership formalized what had started as a few experiments into a proper business unit, and to address the reality that their customers consisted mostly of their competitors, they spun off a new entity, called HOAM Ventures, tapping Brock as president and CEO, a title he would add to his existing one Associa’s CIO.
If you, too, are a CIO seeking expanded roles in the C-suite, you’re likely wondering: How can I emulate this strategy? Brock, who admits that luck and timing have been paramount in his career, modestly offers the following advice.
Brock says he never would have earned more responsibility had he not brought order to IT proper. “Our systems had to be up, stable, and secure, and if any of that went off the rails, I would not have had the time or confidence of my peers to pursue this path.”
He emphasizes the importance of hiring leaders that can “manage the operations as you are leaning into the white space,” and he rejects the notion that, by empowering such a team, you might render yourself redundant. “It can be scary letting go, but it’s a necessary step to allow the space required to determine your beachhead, and, ultimately, scale any business.”
Brock suggests that, if, as a CIO, you lack a cross-functional upbringing, you can build these aspects of your resume in myriad ways. For example, you could volunteer to lead a large acquisition integration, which Brock sees being especially relevant. “You’re analyzing a company, function by function, examining their merits, and figuring out how to put the pieces together to maximize value.” Moreover, the highly cross-functional nature and visibility of integrations can only help you gain relevant experience, he says.
If your company isn’t acquisitive, Brock advises joining the steering committee of another cross-functional transformation program, an opportunity available to most CIOs. When such a program is executed thoughtfully, it wins hearts and minds, adding stamps to your functional passport.
Even with the right team and resumé, ascending to “CIO plus” requires some self-advocating. “Nobody is going to ask you to take on this role,” Brock explains. “There’s a lot on you to make your intentions known.”
For Brock, this meant talking with CEO John Carona. Brock recalls expressing early on that, while he was grateful and honored to serve as CIO, he was open to more. “I shared that if the opportunity were to present itself, I was keen to explore a broader leadership role,” he says.
Additionally, as he was coming up, Brock carefully cultivated his brand, so that when he would in fact get the chance to expand his responsibility, his peers would support his candidacy. “Of course, I’m the technology specialist when it’s needed, but that’s not how I brand myself or operate within the organization,” he says. “I try to ask operational and budgetary questions that demonstrate my grasp of the business. If you aren’t intentional about this strategy, you could get pigeonholed.”
Luckily, as CIO, you have a unique purview in the organization. “You’re the only person that can see holistically across the organization and how all of the systems, functions, and process work together,” Brock says.
By coupling this view with your responsibility to chart the company’s digital transformation, you discover new avenues to create areas of opportunity, he points out.
“There’s bound to be customer and business needs adjacent to technology that haven’t been explored: This is your chance to stake your claim. You have to discover it, want it, and raise your hand,” he says.
