Design Principles: how to manage them

I have already blogged on the topic of design principles: how to get good ones; more about design principles.  But I was stimulated by some questions from Hans-Christian Grung-Olsen.

Before I comment, let me clarify what I mean by “design principles”.   This is a jargon phrase referring to statements (usually single sentences) that a design team creates (or sometimes they are provided by the “client”) that define the most important guiding thoughts for the design work.  Imagine that you are redesigning your kitchen.  What would be the most important guiding statements that you might give to the kitchen designer?  “I want a light, bright kitchen that makes me want to jump out of bed for breakfast”.  “The design must enable us to have six people round the table”.  “The design must have an aisle near the cooker for preparing food and laying out dishes”. “Work surfaces should be xx inches high”.  “There should be two sinks, under the West window”.

As you think about these statements, you can see that some of them are very specific – “xx inches high”, while some are broader, allowing more flexibility for the designer to find a creative solution – “light and bright”.  Some design principles are about big structural choices “an isle near the cooker”, others are about minutiae “at least one power point with a slot I can use to charge my mobile phone”.

One question that Hans-Christian asked is about how to deal with all these different kinds of guiding statements.

Try to keep the number of statements (for each level of design work) to less than 10.  Three is often better than 23.  This is because the human mind finds it hard to be influenced by more than 6 or 7 thoughts at the same time.  Hence, if you want the designer to do good work, don’t given him or her more than six or seven thoughts at a time.  Additional statements can be added as the design work progresses to lower levels of detail. Bring in the statement about electric plugs, when the electrician is making choices about what plugs to place in the wall.  Bring in the statement about the height of work surfaces when the designer is working on the heights of work surfaces.

The first level of design is usually architectural or structural, so your first set of design statements should be aimed at giving architectural guidance.  Here, you can get the designer to help.  “Is this statement useful to you, at this stage of your design work, or is it too much detail or too constraining or too vague?”  Often the designer will respond “It feels too constraining.  Can we take the thought up a level?  You are saying you want an aisle near the cooker, but I am hearing that what you really need is somewhere to prepare food and lay out dishes.  If I come up with a design that fulfils this need, but does not involve an isle, would that be OK?” “You say you want two sinks under the West window.  How important is two sinks? How important is ‘under a window’?  Does it have to be the West window, why?”  So, you or the designer should probe every statement for its relevance to the design work that is being done now, and for the nature of the guidance that is contained in the statement.

When this process still leads to 20 statements, the designer should demand some forced ranking.  “Which are the most important 10?” or “If I have to make compromises, which of these would you be prepared to compromise in order to ensure the others are fully met.”

The designer then goes away and does a first draft or some options.  If the first draft is acceptable, the designer can then start working on the next level of detail: the positioning of lights, the material used for surfaces, the layout of cupboards or the positioning of electrical equipment. 

At this point the designer will want more guidance: statements that define requirements or preferences for this next level of detail.  There are often frustrations as these lower level design requirements become clear.  “I wish you had told me earlier that having the dishwasher near the plate cupboard is important to you. This probably means we should move the table closer to the door, and this means I will need to redesign the shape of the work surface”.  The lower-level requirements can sometimes turn out to influence higher-level design choices, causing some iteration and rework.  But this is a cost worth paying, for the benefit of having a manageable number of statements at the higher level. 

Hans-Christian also asked about design requirements that feel as though they are not specific to the design work that you are doing, but could have an influence.  For example, “I don’t want the kitchen to get too hot in summer” or “We should think about the impact on the environment” or “We might have grandchildren in the future”.  These kinds of statements should not be included in the 5-7 most influential design principles.  But there is no harm in thinking about them once a design has been developed: “are there any adjustments to this design that we might want to make because of our concern for the environment or because our daughter is getting married next year?”

Using design principles in design work is an art not a science.  There are two thoughts that will help you as you develop your approach: first, keep the number down (below 10); second, make sure each design principle is relevant to the level of the design work that is being done next.  And, of course, use some of the techniques described in my earlier blog for ensuring you have good quality statements

Posted in Uncategorized | Tagged | 1 Comment

Operating Model work is simple

Tom Graves from Tetradian has just posted a wonderfully elegant thought on LinkedIn, which I include below. He is a leading thinker in the fields of business and enterprise architecture – fields that overlap a good deal with operating models.

“What is architecture? What do we do in architecture? And how do we do it?

Turns out that it’s essentially the same for every kind of architecture: enterprise-architecture, solutions-architecture, software-architecture, building-architecture, naval-architecture, brand-architecture, whatever.

Right down at the root, in principle, architecture is incredibly simple. It all comes down to just one idea, one aim: that things work better when everything works together, on purpose.”

I love simplicity. But, I don’t think that the sentence in italics is quite complete. Building on Tom’s insight, I have added a thought: Things work better when everything works together for a purpose, on purpose.

“On purpose” means that we have made design choices with the intention of ensuring that “everything works together”. The reason why the sentence also needs the phrase “for a purpose” is because we only need everything to work together if we are trying to get something done efficiently. So the start point of all architecture and all operating model work is clarity about what we are trying to do – the purpose.

In my approach to operating model work this clarity involves defining three things: for whom are you trying to do something (the customer), what is it that you are trying to do for the customer (the product or service) and what activity do you believe you need to do particularly well in order to create value for the customer. These three elements are written in the singular: customer, product and activity. But in most cases operating model design work involves multiple customer types, multiple products or services and multiple special areas of needed competence.

Hold onto the “working together… for a purpose, on purpose” thought, and you will not go far wrong. Start with clarity about who the customers are (not always obvious, especially with internal functional design) and what the organization is trying to do for these customers (often not clearly defined). Then lay out the work steps that need to be done to create the beneficial outcomes for the customers (the value chain or chains). Then identify which work steps it is most important to do brilliantly well. Then design everything towards this end, recognizing that it all needs to “work together”.

Of course, operating model design work is easy to describe, but difficult in practice. As Tom adds:

“What we end up with should be simple – or as simple as possible and practicable, anyway. But we often have to go through a lot of complexity before we arrive at that simplicity. People, processes, politics and petty feuds, technology, temper-tantrums, structure, story, hopes, fears, wishful-thinking, delusions, disasters, doubts, debt-collectors, nightmares of logic and logistics, lost-in-translation tangles, things that just don’t work, things that do work in surprising ways, and maybe a little bit of magic, too: successful architecture covers and copes with all of that, and more.”

If you keep the simplicity of what you are trying to do front of mind, and recognize that you will often be wrestling with dilemmas and constraints and difficult people and seemingly impossible contradictions, you will do great work.

Posted in Uncategorized | Tagged , , , | 1 Comment

How to design for agility

I was stimulated, by an article in the Journal of Organization Design, about how to do design work recognizing the need for agile evolution, the fact that designers do not always get it right and the fact that people don’t always behave as planned .

Good design does not always lead to a good organization because the designers are “boundedly rational”, and because people have their own wills which can cause them to act in unpredictable ways.  Also, a good operating model for today may become less good tomorrow because the environment changes in ways that require new tasks or require tasks to be executed in new ways.

Agility, as I am using the word in this article, is the ability of organizations to adjust as circumstances change. But it is also the ability to adjust when part of the design that has been developed proves to be ineffective, either because the design is wrong or because people do not follow the design.

So why do people behave in ways that are not intended by the design.

First, they are influenced by the challenges they face, which may not have been anticipated by the designer.

Second, they have their own ideas about what tasks are most important, which may not always be the same as the intentions of the designer

Third, they choose behaviours that they believe are most effective for completing the task, which may not be the same as the behaviours that the designer thought were needed, and

Fourth, they choose behaviours they believe are most beneficial for them personally (personal rewards) and for their team or department and these can be in conflict with the behaviours that are most beneficial for the organization as a whole.

So what does “designing for agility” look like in practice?

We need to start with a definition of “good organization”. Good organization is an organization where “capable people work well together”.  “Capable people” means people with the skills and personality suitable for the task combinations they are allocated.  “Working well together” means that the people interact effectively where their tasks involve working with others in the organization.

Armed with this definition, “designing for agility” means:

  1. having a good understanding of which tasks need to be executed particularly well for the organization to succeed (which behaviours are critical to success) and how the people responsible for these tasks are currently behaving (if an organization already exists).
  2. focusing on achieving a fit between the person and the task, particularly for the most important tasks and most powerful people.  This is about the “capable people” element of good organization. Fit occurs when the person already has the relevant skills, values, behaviours and understanding of priorities needed for the task. In these circumstances the slipage between intended behaviour and actual behaviour is likely to be low, at least where the intended behaviour is appropriate for the job. To go from mistfit to fit The designer will need to adjust the task or the person or both.
  3. focusing on designing solutions to “difficult links”: important interactions between people that are likely to be (or are known to be) suboptimal because of conflicting objectives or competence issues or personality issues or …. This is about the “working well together” element of good organization. Design solutions may involve adjustments to people, to task definition, to interaction protocols, to leadership structures, to incentives, to information systems, to locations or to ….
  4. designing strong performance accountabilities, so that areas of “misfit” or “difficulty” that impact performance are quickly exposed.
  5. “fast redesign”, whenever a “misfit” or “difficulty” emerges. A “misfit” or “difficulty” may emerge because the design was inappropriate, because the people are not behaving as the design intended or because circumstances have changed. Managers should be encouraged to think like the manager of a football club.  If a person is injured – redesign.  If a person is not executing their tasks well – coach or redesign. If we are losing the game – coach the team or redesign. If two people are not working well together – coach them or redesign.  Every manager, therefore, needs the authority to redesign in their own area, as well as some competence at or support in good design.
  6. creating “design authorities” at different levels who can check whether the continuous process of small redesigns is challenging the overall working of the operating model or whether broader operating model changes are needed. The process should not be an approval process, which would slow down the redesigns.  It should be a review or audit process, which raises red flags when a small redesign may have consequences that have been overlooked.
  7. designing a process that enables managers at all levels to signal the existence of and drive the resolution of “organizational tensions”: a “misfit” or “difficulty” that is not part of their authority, but is effecting their ability to execute their task.  This process needs to be like the “tensions” process in holacracy or like the “Andon cord” on a Toyota production line.
  8. putting in place a culture and a reward system that reduces the natural forces of self-interest and department-interest which can distract from “organization-interest”.  Managers also need to be supported with training that will help them evaluate the “organization-interest” when making small redesigns.

Since the enacted or realized or real organization is how people actually behave rather than how the operating model design expects them to behave, all design changes should focus on what actual behaviours are likely to result, given the actual people involved, the current cultural norms that will be difficult to change and the likely pressures on the organization that may affect behaviour. The enacted or realized organization emerges from the combination of the formal design plus the informal behaviours. Design work is mainly about designing the formal organization, but this should always be done with an eye on the likely impact the changes will have on actual behaviour.

Posted in Agile and operating models, Tips for design work | Tagged , , | 6 Comments

Thoughts about HR and Operating Models

I was stimulated by this “4 stages of HR maturity” graphic, which was shared on a LinkedIn post. I am not sure of the original source.

There were more than 30 comments against the post, all of which were complimentary, saying how useful and helpful they found the graphic. This caused me to have a closer look because I do a bit of operating model work on HR functions and often find that HR strategy is not well defined.

What I want to share here is a critique of some of the content in this graphic, and point out that this kind of “maturity scale”, while seductive, is unhelpful. As my tools, such as the operating model canvas and the value chain map, point out, HR (or any function) needs to define who its customers/beneficiaries are, what value it aims to deliver to these customers/beneficiaries and what work it needs to do to deliver this value. Of course, in some areas an HR function may have an ambition to deliver value, but not yet have the capabilities to fully do so (for example business partnering in many HR functions). The capabilities to deliver this “value proposition” may be “immature”. But, to suggest that there is a maturity scale for the whole of HR is to misunderstand what is going on.

Now to some specifics in the graphic.

First, HR Reputation: HR should aim “to help the organization succeed given the legal context”. Aiming for best practice or external plaudits or just to help the organization be compliant are inappropriate for any HR team. HR exists to help the organization succeed and it should want to have a reputation for achieving this.

Second, HR Customers: HR has many customers and it should be clear about the different customers it has (Board, employees, managers, etc) and the value that it seeks to deliver to each of these customers (reports/advice to the board, services to managers, etc). Phrases like “we are employee champions” or “we are strategists” get in the way. For some customers HR may act as a champion. For other customers, HR may provide strategic support. What is vital is that someone has thought through all of the different customers and their needs, and is clear about what HR is providing to each.

Third, HR Purpose: HR exists to deliver the value (services, etc) that is has been set up to deliver. In some services HR may be delivering basic support. In some it may be delivering innovative solutions. In some it may be impacting external stakeholders. The key is to be clear about the ambition/promise for each service HR is offering. When considering the “service portfolio” some kind of scale, such as implied in the graphic, may be useful. Some HR functions may aim to provide a narrower range of services and others a broader range of services. But the service portfolio that is chosen should depend on the needs of the organization and the capabilities of the HR team. The vast majority of HR functions aim to deliver a broad range of services.

Fourth, HR practices: the scale in the graphic implies that first you need to be able to deliver “essential work” before you can deliver “leading edge” and this before you can deliver “strategy enabling”. This misunderstands the role of HR. As my point under HR Reputation states, HR should aim to deliver “strategy enabling” practices. Delivering essential work is “strategy enabling”. “Leading edge” is not necessarily strategy enabling. First it is impossible to define what is “leading edge”. Second, the pursuit of “best practice” often gets in the way of “helpful practice” because it encourages HR professionals to look at what other companies are doing rather than focusing on what our organization needs.

I could go on. My point is that a graphic like this is seductive, but can lead us away from clear thinking about HR. Tools like the Operating Model Canvas and the Value Chain Map are much more helpful.

Posted in HR, OM frameworks | Tagged , | 2 Comments

Supplier relationships

An important topic in any operating model design is the design and maintenance of good supplier relationships.  The first step is to decide what should be done in house versus by suppliers.  For this, use the “supplier matrix” tool.  The next step is to design relationships with those suppliers that cannot be treated in a transactional way: these are tasks for which there are not ready alternatives to the supplier or ones that are particularly important to your success.   “Relationships” will include a formal or informal agreement that addresses “the purpose and strategy”, “who does what”, “who owns what” (important for IP or data), “how the performance specifications are defined and monitored”, “incentives and penalties”, and “how the relationship is dissolved”.  The “relationship” may be a formal JV, a contracted alliance or an informal understanding.

I was recently reading a McKinsey article on how to do a “health check” on these “designed” relationships.  The advice was pretty straight forward: clarify the purpose and strategy, collect performance information and then talk to leaders of both organizations. But the article also contained a list of six aspects of good supplier relationships … and it is this list that caused me to write this blog.  I partly agree and partly disagree.

  • Strategy—gaining agreement on the partnership’s objectives
  • Culture and communication—encouraging open and trust-based communication among all parties
  • Operations—establishing a new operating model and performance metrics (for instance, sales or quality-assurance metrics)
  • Governance and decision making—adherence to key decision processes, metrics regarding speed of decision making, stage gates, and time lines
  • Economics—defining how value will be created from the partnership
  • Adaptability—proactively planning how to “tend” the relationship over time, in the wake of industry and organizational shifts

I agree with “Strategy”, “Culture”, “Operations” and “Governance”.  All vital elements worth real attention in the design.  But “Economics” as a separate topic from strategy makes no sense to me.  Strategy should be primarily about the value that the partnership/relationship is trying to jointly create.  To think of strategy as a topic separate from value creation seems to me to misunderstand strategy or value creation.

Then I also felt uncomfortable with the final item “adaptability”.  In my nine tests of good organisation design, the last test is the “flexibility test”: will the organisation find it easy to change/flex/adapt to the changes that may be needed in the next couple of years?  So it is very similar to the McKinsey “adaptability test”: will the relationship easily change/flex/adapt in the wake of industry and organizational shifts.  So I like the point.

But, in my nine tests, I do not have a separate governance test.  I think of governance as covering legal due diligence stuff, like approval of accounts, decision making, especially what happens when people disagree, and appointments of those with “governing responsibilities”.   The ability to adapt to new events/pressures is about decision making and appointments, so it seems to me to be part of governance.  Hence, rather like “Economics”, I think the McKinsey list should either make the “Governance” point more specific or include “Adaptability” within it.

Posted in Supplier Matrix | Tagged , , , | Leave a comment

Five guiding thoughts for good operating model work

I enjoyed reading an article by Marcia Blenko, a Bain & Co advisor, about operating model work for charities –  The article follows the Bain definition of an operating model, which is focused on organisation structure, accountabilities, governance, systems and ways of working.  It does not give as much attention to work processes, location, and supplier relations as the Operating Model Canvas.  Nevertheless, Marcia is an authority in this area and worth listening to.

Her first five guiding thoughts are:

1. Start with strategic clarity

2. Use design parameters (or design principles) to define what matters most

3. Up your game on decision effectiveness

4. Prioritize must deliver capabilities over “good enough” capabilities

5. Look beyond structure

This article is about my reactions to these five.

1. Strategic clarity is a big problem in operating model work, especially in charities.  So I wholeheartedly support Marcia’s focus on this.  The problem for an operating model team, who may not be skilled at strategy work, is to know when there is enough clarity and when there is not.  Few heads of organization are going to admit that there is not enough clarity.  They are more likely to say the opposite.  So I have a template that I get the operating model team to try to complete. If they can complete it, there is enough clarity.  If not, there is a problem.  The template asks the following questions

– what products or services does the organization aim to deliver/offer?

– to whom is the organization aiming to deliver these products or services (often there are multiple customer groups or beneficiary groups)? For charities, one of the “customer groups” may be donors.  So, it is important to understand what the “service” is that is being provided to donors.

– in which locations/geographies is the organization aiming to deliver/offer these products/services?

– through which channels of delivery will the products or services be offered?

– what does the organization aim to have as its sources of excellence or advantage?  These are normally operating capabilities.  But they can be brand or location or a range of things.

– what operating initiatives/transformations are underway or likely to be initiated in the next two years.

2. Design parameters or what I call design principles are also critical to good design work.  They help limit the number of options that need to be considered and focus design attention on the most important aspects.  I agree with everything Marcia says on this topic.  Again, I have a template to help with this work.  It has three columns.  The first is for the design principles (each a sentence that typically starts with “The design must enable ….).   The second column addresses the question “why is this principle important”.  It is useful to keep asking why, until the answer links directly with a high level strategic objective.   The third column provides space for listing implications for the design.  Here the design principle is converted into design ideas.  The value of this column is that it helps make sure the principle really does have design implications.

3. Decision effectiveness is a big focus of Bain & Co’s consulting work.  I agree that it is important, and I recommend using their tool – RAPID.  But, I typically do not give it as much focus as Marcia does because organizations need to be flexible and responsive.  Decision rights at time A may need to change for dealing with things that happen at time B.  As long as roles are clear and people are competent with regard to their role, they can adjust decision making rights to suit the change in situation.   So I mainly use RAPID only where there are “difficult links” that need to be designed at a lower level of detail.

4. Must deliver or critical capabilities are also central to the way I think about operating models.  You should avoid making design compromises with regard to critical capabilities.  But you can make design compromises for “good enough” capabilities.  I use a value chain map to help pin point these critical capabilities and to help me assess whether I am compromising them.

5. Structure is just one design lever.  It is a powerful one.  But we should not think of it as the only one.  In fact, I like to say that all of our design levers, only design the formal organization.  The real organization is the informal organization.  We make changes to the formal design in the hope that it will influence informal behaviours. Unfortunately, it often does not.  Culture eats design for lunch!

The article mentions three more guiding thoughts, which I have not included here because I think they are less significant (and this article is getting too long).  I will let you discover them for yourself.


Posted in Decision grids, Design principles, Design tools, Strategy, Tips for design work | Tagged , , , , , , , | 2 Comments

Finance function operating model

I was recently asked to give some help to a team working on an operating model for their Finance function.  The prime objective was to upgrade the function, so that it added more value and cost significantly less.  The particular discussion was about organization structure: who should report to the CFO, how to free up some of the CFO’s time for interacting with stakeholders and for spending more time on business strategy, and how to resolve the overlaps between “controllership”, “FP&A”, “strategy” and “performance management”.   In this company strategy reported to finance.

My first recommendation was to do a value chain map.  This was not because I expected there to be significant overlaps or common capabilities across value chains, but because the teams did not seem to have made a clear list of the “value propositions” of the Finance function.  You cannot do a value chain map without first defining the value propositions for which you need value chains.

The list of value propositions included things like “Provide a controllership function”, “Provide tax services”, “Provide treasury services”, “Produce management accounts”, “Propose changes to the portfolio of businesses”, “Influence performance outcomes”, “Help set budgets and KPIs”, etc.   We had a list of nearly 15 value propositions.

When we laid out the value chains, we noted that there was very little commonality across value chains.  Yes, a number of value chains involved analysis.  But we concluded that tax analysis is a different capability from internal audit analysis or portfolio analysis.  Also, most value propositions involved some partnering with the business divisions.  But, we concluded that strategy partnering is a very different capability from treasury partnering or risk management partnering.  So we concluded that any organization design for Finance should have a person in charge of each of the value propositions, with all the resources needed to deliver the value proposition.  This meant that cost cutting would have to happen within each value proposition or some value propositions should be dropped.

We then needed to think about how to group the 15 (or so) value proposition owners for the purposes of reporting to the CFO.  Ideally we only wanted 5 or 6 direct reports to the CFO to help free up some of her time.

Some value proposition owners (or departments) needed to report directly: Strategy, Internal Audit and Treasury.  So the question became “how to group the rest” and whether some of the rest could report to Internal Audit or Treasury or Strategy.  This raised some interesting debates about whether M&A Support and/or Performance Management could report to Strategy.  I counselled that I thought that both M&A and Performance Management were incompatible with Strategy because Strategy is about reasoning, creativity and intellectual rigour, whereas M&A is about deal doing and Performance Management is about holding people’s feet to the fire even when it seems unreasonable.  But we observed that many companies do put some of these activities together.

A number of logics for grouping departments were discussed

  1. Operations type activities, like accounting; specialist departments, like tax, treasury and M&A; departments with heavy interaction with business divisions, like FP&A and Strategy
  2. Activities with an “innovation” orientation, like Strategy and Tax; activities with a “customer intimacy” orientation, like FP&A and Risk; activities with an “operational effectiveness” orientation, like Management Accounting or M&A support
  3. Activities that are primarily about setting policy, like Controllership and Risk; activities that are primarily about shared services, like Management Accounting and M&A support; activities that are primarily about “influencing”, like Strategy and Performance Management

To date, no decisions have been made.  But I thought you might find the process of thinking interesting.

Posted in Finance function, functional alignment, Value chain | Tagged , | 16 Comments

The Operating Model Canvas, Kaizen and Agile

This week I was in Bologna and Vicenza helping launch the Italian edition of Operating Model Canvas.  The translation and funding for the Italian edition was provided by Kaizen Institute: who support companies wanting to improve their operations.  I was giving a presentation on the Canvas and toolkit.  There were also presentations from the Kaizen Institute explaining how they integrated the Canvas with their work on processes and change.  I wanted to share some observations and learnings.

First, the Kaizen approach is built around “value streams”: observe and document each value stream, imagine ways in which the value stream could be improved, try out the good ideas, then operationalize, then monitor and measure improvements.  The value stream focus of Kaizen is similar to the value chain focus of the Canvas.

Second, because the Canvas is looking at more than processes, it has been providing the Kaizen Institute consultants with a “whole system” way of understanding their client organisations and of explaining to their clients why they should be considering more than just process improvement.  Often process improvements are only possible if wider changes are made to the operating model and sometimes the improvements will only be sustained if reinforced by other changes in the operating model.

Third, the Kaizen approach exposed me to two aspects of what I call “management system” that I was previously aware of, but had not fully connected with management system.  The first is Hoshin Kanri, the process for “deploying” strategic ambitions through change projects. Companies, such as Danaher the US conglomerate, are devotes of Hoshin Kanri, using this management system to define “breakthrough” projects, set priorities and drive change. Clearly Hoshin Kanri is a part of “management system”.

The second aspect of the Kaizen approach that is part of management system is the upwards cascade of review meetings that starts with the daily team meeting of operators on the production line, then the daily meeting of shift or line supervisors to connect across teams, then the daily meeting of production managers, then the weekly meeting of functional heads including production and finally the monthly business meeting.  This upwards cascade helps correct issues speedily at the level where they occur, but also ensures that a small issue low down in the organisation that has a big business-wide impact is raised up to the business meeting, and does not rely only on more informal lines of communication.

This recognition that even the lowest level daily stand-up is part of the “management system” made me think about the management system of “agile”: backlogs defined by the team, product owners who prioritize the backlog, kanban boards showing the progress of items that are taken out of the backlog, daily stand up meetings, sprints, etc.  Agile is an operating model: it is an organisation structure (multifunctional teams or “squads” each part of a separate “mother function or chapter” linked together into a “tribe”) where the team members are co-located, typically operating out of one shared space, and everyone is guided by a management system, often called “scrum”.  So we have the work (backlog), the process (sprints), the organisation (squads, tribes, chapters and …), the location (one shared space), the information system (many visible displays) and the management system (backlog, kanban and scrum).  We are only missing the “suppliers” element from the Operating Model Canvas, which, of course, is very specific to the type of work that the agile team is doing.

Posted in Operating Model Canvas | Tagged , , , | 4 Comments

Doing “genuine” work and being “genuine”

I have always been a bit suspicious of terms like “authentic” leadership or “genuine” leadership.  So I was interested to read Travis Bradberry’s “12 habits of genuine people” in Forbes.

I had two reactions.  First, there is some good stuff here: some of which I do and some of which I do not do.  So some personal lessons for me.  Second, surely a “genuine” person would not need to package their thoughts into 12 habits.  The person would more likely list a handful!  So here goes.

  1. Genuine people don’t worry if some people don’t like them.  They know that some will and some will not. They don’t try to please, to win favor.  They are pleasant because they like to get the best from people.  They are willing to take unpopular positions, if they believe them to be right.  Depending on their personality, they may show off or show some ego: but not just to get attention.  They use it to help them get their message across.
  2. Genuine people are open minded.  They are always willing to consider and debate the views of others.  They do not sway in the wind.  Their own views are well anchored and open for others to challenge and debate.
  3. Genuine people are generous and respectful.  They share openly, confident that the interaction will bring benefits for both.  They don’t have favorites.  They interact based on the potential gain for both parties, neither wasting other people’s time nor squandering their own time.
  4. Genuine people are thick skinned and trust worthy.  They do not easily take offense.  They focus on the content, while recognizing the distortion that may have come from emotion. They know who they are, which makes it easier for others to trust them.  They don’t hide their weaknesses. They keep their promises.
  5. Genuine people are loving humans.  They stand by family.  They help those suffering.  They execute tough love.  They can be distressed.  They can be joyous.  They like to fool around and laugh.
Posted in Uncategorized | Tagged , , | Leave a comment

A Critique of Deloitte’s Thoughts on Operating Models

I have just read one of the better articles on operating models.  It is from Deloitte, and it appears to describe their approach.  I recommend it to you because it is relatively easy to understand (if you skip over the jargony, fluffy bits), and because, in my view, it has some important flaws.

Let me explain.  First the article suggests that the journey from strategy to success involves – strategy, business model, capabilities, operating model, people/process/technology – see exhibit (if it is a bit blurred, please go to the original in the article)

This use of language relegates the word strategy to what others typically call vision or mission; and the phrase business model takes up the space that others typically call strategy.  There is also an interesting step – “capabilities” – between business model and operating model, which I want to say more about.  Lastly, people, process and technology is seen as separate from operating model.  Whereas most of us think of people, process and technology as the heart of operating model.  The point I am trying to make here is that you need to be thoughtful about consultant frameworks: challenge them; make sure you understand them; look for gaps, overlaps, language differences, etc.

The flow of questions behind the framework seem logical and sensible.  But, how can you answer the question “who has ownership and decision rights?” without having first defined an organisation chart?  How can you decide which capabilities to buy in before you have defined the operating model?

Moving on to the capabilities box.  The authors are clearly influenced by the Enterprise and Business Architecture view of operating models, which places the concept of capability in centre stage, along with the concept of a capability map.  They provide a very accessible exhibit explaining Deloitte’s version of these two concepts (I suggest you go to the original in their article).


My concern here is that capabilities are being defined away from their operating model context.  Lets take “consumer marketing” (top of fourth column), which is presented here as a capability within the function Marketing.  First, this display, encourages the idea that there will be a function “marketing” rather than some other configuration.  Second, having only one capability titled “consumer marketing” encourages the idea that this is only one capability.  In my experience, consumer marketing for ice cream is a very different capability from consumer marketing for spaghetti, which is different from consumer marketing for knitwear.  By this I mean that, if you took someone who is a good consumer marketeer in one of these sectors and moved him or her to one of the other sectors, he or she would on average fail to perform well, without learning new skills.

It is for this reason that the Operating Model Canvas focuses on value chain maps rather than capability maps.  I believe that you first need to understand the different customer segments you want to serve and the value propositions you believe will succeed in these segments (this is what I call strategy).  Then you need to define the work processes (value chains or capability chains) needed for each of your value propositions.  This gives you an understanding of the work (capability) in its context (value chain).  So if you want to sell ice cream, spaghetti and knitwear, you will have three value chains and are likely to have a work step in each of these value chains called “marketing”. You can then consider whether some of the capabilities in different value chains (e.g. consumer marketing across these three different products) are similar or not.  Configuration (value chain), I believe, comes before capability analysis, not afterwards.

So, my flow from strategy to success might be something like this: mission/vision/values; strategy (what, to whom, how will we get advantage); high-level operating model (value chain first, then organisation model, then other elements including location and sourcing); then high-level financial model to make sure the high-level operating model is viable; then more detailed operating models for those critical capabilities that are to be delivered in house.

This flow differs from the Deloitte’s flow in a few ways:

  • There is no business model step separate from strategy or operating model. If you use the business model canvas, then strategy deals with the right-hand side (value propositions, target customers, channels and customer relationships) and operating model deals with the left-hand side (activities, resources, partners).
  • There is no “capabilities” step separate from the operating model work. The two are intertwined, and much of the capabilities work is done at a lower level of detail
  • There is a recognition that operating model work needs to be done at multiple levels: high level for the whole organisation, medium level for each function in the organisation, low level for each department or capability in each function.
  • There is a financial model step – as in the business model canvas – which needs to be done when strategy is being developed, then repeated for the high-level operating model, and so on.

I may seem rather critical of Deloitte’s article. But, actually, I rather like its clarity and willingness to convert ideas into visuals.  I particularly like some of the material in the section “Where does work get done?”, which is not about location, rather it is about outsourcing and building capabilities.

Thank you Kwan, Schroeck and Kawamura.  It would be great to meet up and debate these issues.

Posted in Capabilities, OM frameworks | Tagged , , , , , , | 5 Comments