Driving Business Value through Your Operating Model and Org Structure

See examples of frameworks discussed in this podcast in our Operating Model Toolkit.


Introduction

Michael Daehne: Hey y’all. Welcome to Inflect. I’m Michael Daehne, and on today’s show I’m joined by Jeff Dixon, a longtime friend and collaborator with deep expertise in operating model design, org structure, and talent strategy.

A lot of our clients are navigating some form of transformation right now, and the people side of that is often one of the most challenging aspects. Jeff is one of the best at helping leaders connect strategy to structure to people in a way that actually drives value.

In today’s discussion, we dig into capability maps, contribution statements, and leadership alignment, and explore how these tools and frameworks help CIOs and other business leaders tackle challenges like AI org design, IT-business partnership, and modern project governance.

I hope you enjoy our discussion as much as I did.


Opening

Michael Daehne: Hey, good morning, Jeff.

Jeff Dixon: Good morning. How are you, Michael?

MD: I’m doing well. How are you?

JD: I’m doing great. Thank you.

MD: I really appreciate you joining. As we’ve talked about offline, everything in the operating model and org design and talent world is top of mind for our clients right now. It’s a conversation we are having every day, and so as you and I were talking, I thought, man, how great would it be to bring Jeff onto the podcast and discuss some of your expertise and approach on all things operating model and org design. So, I appreciate you graciously offering to be here and share some of your expertise and pearls of wisdom with us.

JD: You know this topic is near and dear to my heart, so I’m absolutely delighted to be part of the conversation, Michael.


Operating Model Design Frameworks and Tools

Michael Daehne: Awesome. Well, let’s jump right in because I know there’s a lot we want to cover. There’s kind of a lot of words floating around there in this, in this world of operating model and org design, you’ve talked about capability maps, contribution statements, alignment of leadership.

Can you kind of zoom out and talk about your overall mindset and thinking on how you approach operating model design and some of those components?

Jeff Dixon: Absolutely. I mean at the foundation, as you well know, it always starts with strategy and vision. What ultimately is the organization trying to achieve? And then at its essence, contribution statements clarify the value that each function brings. And then in turn, capability maps, break that down into, say, five to six key capabilities per function. And then things like talent management or digital sales enablement, so that leaders can see where duplication or obvious omissions exist. And then the leadership alignment comes from using these maps, if you will, as a common language to decide on what are the critical capabilities, and therein the priorities that are required in order to execute successfully under the new operating model design.

MD: Yeah, on this idea of capability maps, I envision that when you sit down with a leader to say, “Hey, let’s build out a capability map,” maybe listing everything is not the hard part, but determining what’s truly critical to the business unit success and maybe differentiating that might be the harder part.

How do you help work through that part of the process?

JD: Yeah. It’s a great question. So, obviously you start by defining the functional areas of responsibility that are essential to the business unit success. And those are really the anchors that are across the top of the capability map. So, you know, just kind of envision a grid and at the top you’re really looking at those key functional areas.

And then from there we identify five to six key capabilities under each of those functions that are designed to enable that value delivery. And then, to test whether a capability is critical, we really look at three things. One, does it directly support the business strategy or the value proposition? Is it a differentiator in the market or for our customers? And finally, is it emerging or evolving fast enough that it requires a new investment or new talent in order to activate that?

And in that process, we’ll do some benchmarking against competitors of the industry to see what’s new or shifting. But the goal is definitely not imitation. It’s to clarify where we can distinguish and differentiate, as you said, the business. And then that balance becomes the blueprint for organizational structure and design.

MD: That makes a lot of sense. As you keep carrying that process forward, how do you start to group or align those across teams and functions?

JD: Yeah, we use something called the capability framework and think of it as really the connective tissue between the strategy and the org structure. So, the map tells us what capabilities exist or need to exist, and then the framework shows how they interact and where ownership should sit in those component parts, if you will.

And in that design, we ask a few grounding questions. It starts obviously with the customers: who are they, whether it’s internal or external, and what capability serves them? And then, what is the value or product that’s being delivered and how does work flow into and through the organization? That’s a really key component of that process.

And then ultimately, where do natural touchpoints or dependencies exist between the teams as a result of looking at that workflow? So, Michael, when we answer those, we can see which capabilities should be centralized for scale and consistency, like data engineering or modeling, and which should be embedded close to the business, like customer insights or storytelling.

And then that analysis often reveals integration points that the org chart alone just doesn’t give you visibility to. It helps leaders visualize how value actually flows through the organization, where friction might exist, and where collaboration is absolutely essential.

MD: Yeah, I think, I think one of those last points you made really resonates with me, which is the hidden touchpoints or hidden integrations that an org chart does not show. I think all of us are like programmed to think when we hear the word operating model or org design, to think about an org chart.

Like, I have to jump to the answer, build the org chart, who reports to whom? what’s the structure? spans and layers. And I think, you know, something you taught me a long time ago and I think is coming through in this conversation is, that’s later in the process. Let’s start more on the strategy, the value, the capabilities, and then really the contribution statements, which is I think a little bit more of the why behind each of them.


The Value of Contribution Statements

Michael Daehne: Tell me about kind of as you jump into that part of the process, the value of contribution statements for understanding purpose and impact.

Jeff Dixon: It’s really revealing when we go through this exercise with leadership. So, the contribution statements, as you suggest, really take it a level deeper. So, they explain why each function exists and how it knows it’s delivering value.

So, for each function, we answer three questions. What value do we deliver to our partners, customers, or the organization? Why do we do what we do? What purpose are we serving? More often than not, when we go through this process, we find that our clients are saying, wait a minute. Maybe this isn’t a value-add capability or function that we have in the business. And so how can we repurpose our time, energy, and effort in order to get the most value out of the organization?

And then ultimately, how do we know if we’re delivering that value? What outcomes or indicators prove it? When every function can clearly articulate those answers, it really changes the leadership conversation and stops being about span of control in the org chart, as you suggest, and starts being about value contribution, and where you’re focusing those very finite and essential resources.

I’ll give you an example. HR might say, “Hey, we enable the organization’s growth by building future-ready talent pipelines in a culture of agility.” So that’s not just an HR mission, it’s a strategic contribution that connects directly to capability development and business outcomes. So, when you take the contribution statements together with the capability maps, that really forms a leadership alignment tool.

So, you think of one defining the system of work, that’s really the capability maps. Whereas the other defines the system of contribution and measurement. At the end of the day, when both of those are clear, then transformation really moves from a conceptual to an actionable model.


Tips for Effectively Transforming an Operating Model

Michael Daehne: Yeah, that makes a ton of sense. Um, I ran away for 20 seconds to put the dog in the crate because she was getting into trouble. So, edit this part out or leave it in for a few laughs for our listeners. Um, but I got the gist of it. Oh, never a dull moment.

Jeff Dixon: Never a dull moment.

MD: I think that really sets the stage well, Jeff, for transformation and the role that all of this plays in successful transformation, which we’ve talked about, this idea of operating models is not, it’s not often the first thing leaders are thinking about as they embark on big transformative initiatives, but it often makes or breaks the success of the initiative.

Talk a little bit about maybe some barriers or resistance that they might encounter.

JD: I would say the big three are: one, focus on future capabilities. If you’re going be successful, the willingness to challenge the legacy structures. And then collaboration.

And I want to touch on the thing that you said about the propensity to want to go to the org chart first and foremost. I mean, how many organizations have you worked with, where within a year, a year and a half at most, very often, even less than a year’s time, they’re restructuring the org again? And it’s because they didn’t take the time to really build that scaffolding, if you will.

Focus on Future Capabilities

JD: And so, I focus leadership on defining what’s really the emerging and new capabilities required to best deliver value while looking ahead to the future. The great old adage is, skate to where the puck is going, not where it is. And then not being constrained by those current capabilities or the lack therein.

Be Willing to Challenge Legacy Structures

JD: And then a willingness to challenge existing paradigms about how the organization is structured. This is super important, not only in terms of the functional alignment, but also the leadership across those functions, because as you do that examination, that very often changes the complexion of the organization and where you want to focus your leadership to leverage the best success.

Collaborate

JD: And then collaboration. I know that’s a du jour word, but, it’s absolutely imperative, especially in today’s environment because interdependencies are absolutely imperative in order to be effective in delivering the outcomes that an organization’s looking to deliver.

And resistance is natural, right? Especially when leaders feel that their turf is at risk. The key is to shift the lens and, and essentially set the context, “Hey, you’re not just leading a function, you’re a leader of the entire organization that has been charged with a missive around a particular set of functions to activate that on behalf of the organization.”

Importance of Thinking about the Whole Organization

MD: I think that’s so key. And we’ve talked about this, I see that on a macro level with, I’m going to use air quotes here, “big projects” at large organizations where it’s kind of a red flag for us sometimes when we see a “big” supply chain transformation or a “big” finance transformation or a “big” ops transformation where we’re not zooming out and saying, “how do we optimize the whole, not the parts?” Like those functions individually may indeed require transformation within them. Not saying there’s not value there.

But when it’s too inward-looking within a business function or a business unit or whatever the case may be, I think that is when real challenges and resistance pop up, because to your point that most organizations today are so integrated and cross-functionally connected. It’s really hard to pull out an individual piece.

And so, I love that idea that you’re saying, “how do you empower a leader to think about leading the whole organization and then how that applies to their part?”

JD: Very good. Yeah, you know, there’s that old thing about, hey, you know, I have to do this as fast as possible, and so, the fewer cooks in the kitchen, if you will. And the reality is you’re just compounding the problem and really setting yourself up for failure down the road as opposed to really understanding and examining those interdependencies at the onset.

Example of Benefits from Operating Model Transformation with AI

Michael Daehne: Yeah. I know we talked about a cool example of leveraging AI in talent acquisition that I think plays into this conversation. Can you share a little bit more about that?

Jeff Dixon: Yeah, so we were working with a Fortune 10 client, and they needed to scale their talent acquisition without adding head count. Sounds like probably every organization and ultimately we redesigned the operating model to embed AI across the recruiting process all the way from requisition to slate. So, from the first need that’s expressed to the point of presenting really your finalist candidates.

And really the payoff there was they accelerated the recovery of a $4 million digital investment by a full year and improved time to fill. And that’s a value that you can measure, which is really important to make sure that you’re unlocking value as a result of the new operating model.


AI and Operating Model

Michael Daehne: Yeah, great, great example. And the, the payoff there is really compelling of what they were able to achieve. So, I really appreciate it. I think you’ve done a great job connecting those dots between strategy and structure, value, purpose, how all that fits together.

I think with the remaining time we have, you and I had said, “Hey, how does this show up in practice? Right? What are some of the common pain points that leaders and in particular I think CIOs are navigating right now that are directly or indirectly tied to this conversation?”

Treating AI as a Business Capability, Not Just an IT Project

MD: And it’s things like, AI of course is in the zeitgeist right now. Everyone’s talking about AI. And there’s conversations happening around, do I quote unquote, “hire an AI guy,” have an AI team. Or is it more about embedding AI literacy and AI knowledge with within my team? That’s one example.

I think another one is the evolving IT-business relationship, or what does a PMO look like in today’s world? So, what we wanted to do is talk through a few of those scenarios that we’re seeing pop up at a lot of our clients, a lot of the conversations we have and pick your brain on how you might think through those.

Jeff Dixon: Yeah, very topical. So, I guess what I could share is where I’ve seen success is where organizations have really put the emphasis and the focus on cultivating those AI use cases in concert with the business. And so, you know, successful companies really need to treat AI as a business capability, not just an IT project.

And what I’ve seen work is where you get a sort of a small team as a catalyst, where you build that digital literacy and, in that process, identify use cases with the business that then in turn partners with IT to really pilot and scale that. Harvard’s Tsedal Neeley, she calls this the 30% rule: that you don’t need everyone to be a coder, but you do need baseline digital fluency. And so, if you can build that with the business, then that helps them think about how technology can be an enabler and then you really enjoin them in that process working with the IT organization to really build the genesis of a proof of concept.

Creating an AI Learning Environment to Build Confidence and Competence

MD: I love that way of thinking. You know, we’ve been doing a lot more, we call it Copilot Catalyst work, where we’re helping organizations get going with Microsoft Copilot in a short time span, getting a pilot group of users playing with the tool.

The value that we’re seeing from organizations is not about Copilot. I mean, yes, the different individuals that are working on it are gaining some fluency and capability and using Copilot, but it’s more about giving them a sandbox to play around with something in the AI space. And it’s unlocking this creative thinking for them, where they’re then asking, “Could I do this? Could I do that with AI?”

And a lot of cases the answer is, yes, you can, but not with Copilot. But let’s go talk about some of those other tools, platforms, capabilities you could use. We’re seeing in practice every day exactly what you’re talking about, which is, this idea of giving the business users that AI fluency or AI literacy, whatever you want to call it, so they can get a little more comfortable and then become part of the ideation and the solutioning versus saying, “Hey, IT can you go solve the AI problem for us?”

JD: Yeah. I love that. And it, it really is about building that sort of lab environment and getting the business to not feel that this is so foreboding, right? That there really is great opportunity that lies in thinking about the digitalization of certain component parts of the business and, as you said, giving people the confidence and then the competence to go in and experiment, and then in turn work with IT to bring that forward as a value proposition to the business.

Where and How to Embed Capabilities within the Organization

MD: I totally agree, Jeff, and I think this ties to the age-old question of centralizing versus adding within the business or federating, however you want to think about it. Talk about how you think about those tradeoffs and ensuring that whatever approach you land on works.

JD: Yeah. And this to me is where, you know, starting with that operating model is really essential because, as you do that examination, you can begin to define capabilities that are best centralized in IT, as opposed to others that deliver more value when they’re embedded with the business.

It’s a simple balance. It doesn’t mean it’s easy, but you centralize what requires scale and consistency, like data engineering, and embed what drives business impact, say storytelling and insights.

Now, a caveat to all of that is this hub and spoke model works only if you’ve set up strong data governance and clear ownership. So, again, that’s where, once you’ve decided where those capabilities best reside, then we think about how that works in an operating model around a core value or process, you know, value stream or process. And then make sure that there’s clarity in that so that everybody knows where the decision rights are and who owns what.


The IT-Business Relationship

Michael Daehne: Yeah. Totally agree. This also is a good segue into maybe more of a macro challenge or opportunity that a lot of our clients and friends are navigating right now, which is the IT-business relationship in general.

I read an article recently that talked about a lot of IT teams and IT leaders are used to the business coming to them with a problem saying, “Hey, how can we solve this?”

And AI and modern technologies have made it easier for business users to identify the solution and come to IT with the solution, “Hey, I want to use this tool. I saw this cool AI capability, or I saw this SaaS platform,” or whatever. And I think that’s creating some tension in some cases, or at least evolution around the IT business relationship in large enterprises.

Talk to me a little bit about that strain that IT-business relationships might be experiencing, and how you think about rebuilding trust and responsiveness.

Jeff Dixon: Well, there’s a number of ways to come at that. I think first and foremost, it’s incumbent upon the business to really share what the vision and strategy is of that business or function. And also share the capability maps, and the capabilities that the business is leaning into, right?

Because if we can bring a literal heat map that says, “Hey, these are the areas that we need to leverage in order to differentiate the business,” then you’re really bringing and enjoining the IT organization as a business partner, right? We’ve heard about relationship management being critical to managing the business relationship from an IT perspective. And that absolutely is.

But it also has to be on the flip side where the business is really enjoining them into what is it that we’re trying to do and where are we placing our bets?

So, for example, we had a client that wanted a simpler and more intuitive onboarding process, which really at the core of it, required both IT and the business to come together on automating many of those new-hire provisioning processes. But at the onset, the business was very clear about the value proposition they were driving and what capabilities were they trying to leverage in order to be successful in that process.

Embracing New Ways of Working between IT and Business

MD: I think that example really resonates with me because I think it ties into your broader points on trust and maybe clarity is another good piece there on roles, responsibilities, handoffs. You know, a product operating model is another kind of hot topic right now for organizations shifting.

What are maybe some practical steps for IT leaders as they think about embracing, whether it’s business relationship management or product operating model, embracing a new way of working?

JD: Yeah. Of course, you know, trust is a trigger word for me. There’s no panacea, but I do believe that where trust starts to erode is where there’s a lack of clarity about role and decision rights. And I think CIOs will do well to clarify the product owner role, if that’s what they call it. There may be a myriad of titles and the decision rights therein, and really define the accountabilities for those key processes.

And, in order to do that effectively, really, you want to map those interactions to avoid any kind of handoff issues, because most breakdowns happen not in the strategy, but in execution, right?

And when that happens, when there’s those breakdowns that naturally is going to erode trust.

And so, the thing is, people don’t fail [processes]. Processes fail people. And so, you want to make sure you have integrity around those processes and everybody’s clear around that because success ultimately is going to show up in the basics: clear workflows, clean handoffs, and everyone knowing who owns what.

So, I think that’s, that’s a central component to really building that trust and enabling trust between the business and the IT organization.

Processes Failing People

MD: You know, this is a little off script, Jeff, but your statement on people not failing processes, but processes failing people, sounds an awful lot like Steve Sarkisian’s post-game press conference after Texas barely beat Kentucky, and everybody wanted to blame the players. And Sark was talking a lot about how he didn’t put them in a good position to succeed because we didn’t have the right play calls, the right accountability, the right communication.

So, you know, I never pass up a chance for a football analogy. I am sitting here thinking that that is, it’s true in football, it’s true in business and, and life too.

I think that’s why this whole conversation is so relevant. It is very easy to look at a struggling transformation or a struggling business function, wherever you’re not getting the results, and finger point at the humans.

Michael’s not doing a good enough job, right? I really wish Jeff was doing better. And sometimes there of course, may be, talent challenges or skillset gaps or whatever, but more often than not, I think it has to do with that process clarity, the handoffs you talked about, understanding of what each function and role is meant to bring to the organization, to optimize the whole.

And so, I think you crystallized that in that last answer. I think that really is a key takeaway for this whole conversation.

JD: Excellent.

Outsourcing versus In-House Support

Michael Daehne: With the rise of SaaS platforms in the last many years, there’s been a corresponding move to outsource application support for large ERP, CRM, loan accounting, whatever the case may be. How do you coach leaders through that dilemma of bringing support back in-house versus relying on third parties?

Jeff Dixon: I think the genesis for outsourcing, unfortunately, was around cost-savings. At the end of the day, there’s so many other factors that need to be evaluated in the course of that process. You know, what’s the data security in outsourcing, the political environment, the oversight demands, and I, I think nearshoring, you know, feels like it’s a way to have more control over those factors.

But whether you’re offshoring, nearshoring, whatever it is, in that outsourcing arrangement, you’ve really got to be clear about all of the value components. And is that really the right move because, more often than not, it creates these phantom processes that actually cost more to manage than what you were looking to save in the course of doing outsourcing.

Whenever we are working with an organization that’s considering that, we deploy an outsourcing decision framework that really helps leaders evaluate those trade-offs.

You know, there’s this adage of, you either buy, build, or borrow the capabilities in the business. And, of course, now the fourth component is bot, right? You know, can I use machine learning and automation in order to affect some of those? You still have to go through the core processes, you know. Those tasks that you’re looking outsource may be better candidates for automation.

You still have to establish clear ownership for the management and oversight of those channels. And the interaction mapping is crucial to that because you got to be clear about what component parts are you outsourcing versus what are you doing in-house, right? We always think about the tier one, two, and three. That’s an important component, but regardless of the complexity of, of what you’re working with from an outsourcing perspective, you still have to have clarity around that framework.

And if we use these team profiles that come from the capability map, we really look at the requisite inputs and outputs that are required, and then you have to do that for your outsourcing partner as well. You’ve got to consider them truly an extension of your organization.

Michael Daehne: I think you hit, hit some critical points in there, and I, I love this idea of buy, build, borrow, or bot, adding that fourth option in there. And I think you hit the nail on the head if you’re leveraging automation or if you’re outsourcing or offshoring, in either case, it goes right back to that earlier point around clarity of purpose, contribution, process definition, all those things that will either make or break the success of the model.


Lightning Round

Michael Daehne: Well, Jeff, thank you so much for sharing all of your expertise and insights on this topic. As we’ve talked about many times, it’s front and center for us and for a lot of our clients and I know, our listeners, so I appreciate you doing that.

Before you go, I have to hit you with the lightning round, my favorite part. So I’m going to start with, what’s one non-tech skill you think every IT leader should build?

Jeff Dixon: Hmm. I’m going to say radical listening, the notion of showing up with curiosity and humility, not one’s own agenda.

MD: Yeah, love that. How about best book or podcast you would recommend?

JD: On topic, the book Designed for Digital. Their five building blocks of digital business success absolutely remain timeless for me, and I think are integral to thinking about any real true digitalization and transformation.

MD: Yeah, you recommended that to me a while ago. I love that.

How about, uh, a leadership mistake that’s taught you something valuable?

JD: Well, I actually learned this in school. As you know, I’m a classically trained clarinetist, so as a first chair clarinetist, I was constantly being challenged for the chair, which means that you play certain passages, you and the person that’s challenging you, and ultimately the quote unquote best player wins.

And I noticed that one of my challengers was in the practice room with our professor on a consistent basis. And I’m thinking, wait a minute. So, I decided I’m going to confront the professor, you know, certain that he was conspiring against me. And then he had this most astonished look on his face and he said, “I didn’t know you wanted my assistance.”

So, that was a core lesson learned for me that you never need to be too proud to ask for help.

MD: Oh, man, ain’t that the truth?  I need that advice for when I can’t find something in the grocery store, also. My wife’s like, “have you asked for help?” So that is a great lesson. Uh, and I love the origin story too and that that has stuck with you.

Okay, last one, Jeff. Best advice you’ve ever received.

JD: It was actually from a former business partner, and his whole thing was optionality. Despite the fact that you may feel absolutely stuck in something, there’s always more options out there than you think at first blush. Allowing yourself, freeing yourself up, and being able to extract what are the various options that are available is really a key to being able to persevere.

MD: Yeah, perfect. And as a business owner myself, that one resonates for sure with me.

JD: I can only imagine.

MD: That’ll be one of many takeaways for me from this conversation.


Closing

Michael Daehne: I sincerely really do appreciate you taking the time and sharing so much with us. I know it’s going to be really useful, and we’re very grateful to have you as a friend of FlexPoint.

So, thank you, Jeff.

Jeff Dixon: My pleasure. Always delighted to be part of the conversation and excited about the things that you all are doing at FlexPoint and look forward to a fabulous future for you and your business clients.

MD: Awesome. Thanks Jeff. Have a great day.

JD: Alright. Thank you, Michael.


Mentioned

Tsedal Neeley

https://www.hbs.edu/faculty/Pages/profile.aspx?facId=438575

 

The 30% rule of needing baseline digital fluency is mentioned in this book:

The Digital Mindset: What It Really Takes to Thrive in the Age of Data, Algorithms, and AI by Paul Leonardi and Tsedal Neeley

https://www.amazon.com/Digital-Mindset-Really-Thrive-Algorithms/dp/1647820103/

 

Designed for Digital: How to Architect Your Business for Sustained Success by Jeanne W. Ross, Cynthia M. Beath and Martin Mocker

https://mitpress.mit.edu/9780262542760/designed-for-digital/

Next
Next

Leading IT as a Trusted Business Partner