Some patterns occur so frequently in organisations that they become the default and almost immune to challenge. Let's look at why and reasons to overcome.
Good article Daniel. I like it and would like to challenge you on a few thoughts.
1. Hierarchical reporting structure.
You actually describe alternatives for people management in your article which sort of undermines your assertion. I think hierarchies are natural in society. Native tribes have hierarchies, open source software has a hierarchy of contributors. There is also plenty of research and evidence that tribal and supportive hierarchies are good for people.
3. Projects are the means of doing work.
and
4. Project-based funding.
Not sure what your problem with Projects is. I realise there is a discussion about Project to Product in the digital domain, and you can throw in a discussion around Operational Process as well. There are a lot of organisational problems with funding models but my assertion would be that project funding done right is actually pretty good.
7. Categorical organisation of strategy.
I'm fascinated to hear what you write about this. My mind is turning cartwheels just thinking about the term.
Thanks Daniel, great article and thanks also for poking me. It provokes a lot of thoughts which I struggle to disentangle. Apologies for the brain-dump.
In my mind I place Hierarchy in my unholy trinity of Silos, Hierarchy and Targets, complete with delightful acronym, as a self-consistent mindset and approach. I find it useful to describe how these elements fit together, skim over the all-too-well know problems with this approach, sketch out the fundamentals of an alternative and then consider how you can change from one to another.
The SHT model
In the SHT model, it is a disappointingly small oversimplification to say that a wise and benevolent CEO starts with a target for the company and divides that into operate targets for functional leaders. For core business functions these are often targets - sales, margin, volume etc. These targets are then split recursively down a tree of mini-CEOs in which everybody is accountable for a neat, quantitive target that sums up linearly to those of the overall company. In this approach, communication and accountability are almost entirely vertical. Often in this model, the manger is also seen as the technical expert with people people promoted. Through the hierarchy through seniority of years or strong personal performance. There is little emphasis on management, strategy or system-building generally and people tend to view leaders as inherently more knowledgable than their teams.
Before skipping over the fairly obvious flaws with this approach, it’s important to recognise it’s strengths - some of which could be an article on their own:
• It is simple, familiar and fractal: Easy to understand, easy to reproduce, no need for any special consideration for anyone.
• It has clear accountability: Each person knows exactly what is expected of them and what resources are available to achieve it. Success of failure is on them.
• It ‘works’ in some contexts: In mature, static, BAU environments where work is individualistic due to well-defined specialised roles it can appear to work adequately. Most commonly ‘sales’ kinds of environments are natural fits, especially when there is the opportunity to factor in long-term customer relationships and satisfaction. However there are clear natural conflicts-of-interest even in these situations.
• It ‘works’ for many people. Many people are at work for the cash and are focussed on career advancement. Many people appreciate an organisational system that allows them to know exactly how they are measured and optimise their behaviour for that.
Of course the flips sides are also very clear:
• While it may be better in mature/BUA environments, this approach is a disaster in development or immature environments characterised by change and uncertainty. In these environment
• Due to it’s simplicity, familiarity and ‘obviousness’ the SHT approach is very often applied where it is grossly inappropriate especially when a former head of sales becomes CEO and generalises ‘what has always worked for them’, or when a company that is 90% applies standard approaches to the ‘change’ areas of the business, which are more and more critical to every company. [I view the fundamental differences between BAU and ‘Change’ work as a primary source of misunderstanding and alignment between departments and individuals]
• Holding people to account for targets is only as meaningful as the targets themselves. Even at the highest level, there are many ways to sacrifice the long term health of a company to spur short-term ‘improvements’ - shipping shoddy products, poor customer service, underinvesting in research and change, etc. It is extremely challenging to develop meaningful objective targets for individuals [and probably not worth the effort] but tightly holding people accountable to bad targets is essentially compelling people to do a bad job. “Optimising for the system” is a polite way of saying “gaming the system” and generally comes at the cost of the comp[any as a whole and/or its customers.
• In almost every area - some more obviously than others - true sustained ‘company success’ is the result of collaboration and alignment between individuals, departments and time-frames. It requires cross-objective prioritisation that adapts as knowledge is required. Precise, individual targets are almost always a focussed drive to the wrong destination.
The COM model (Collaboration, Outcomes, Measurement)
I won’t spend much time describing this as I think the general outlines are very familiar.
• Emphasise horizontal relationships and alignment (Collaboration). At each level, how do we work together to get where we want to go?
• Focus on Outcomes (not activities, not targets). What really matters? Spend time understanding the difference between the goal you are trying to achieve and the symptoms/measures of how to know if you are achieving it.
• Measure what you are doing and incorporate feedback loops. Uncertainty is real, so mitigate it. Don’t build business cases that assert a lot of unknowable things and trigger projects that can never be cancelled because someone would look bad. Measure the achievement to determine the viability of the ideas, not the people. Measure the symptoms of success but don’t go out and generate those symptoms as a substitute for achieving what you really want to. Tying someone’s hand to a board is not a cure for Parkinsons.
In a COM system, as managers/leaders get more senior they are progressively less required for their technical knowledge or ability to act on the ‘front line’. Rather they should show genuine expertise and passion as system-builders responsible for nurturing a bunch of people and ideas into a productive and sustainable whole.
SHT is essential individualistic, based on personal goals, vertical interactions and pseudo-objective personal accountability.
COM is essentially collective, based on shared goals, horizontal interactions and openly-subjective personal accountability.
How can you change from SHT to COM?
• Acknowledge that different working approaches can be appropriate in different areas.
• Look for alignment of very obvious principles (bottom line > top line, sustainable success etc.)
• Identify and convert natural ‘hidden’ allies. There are often some excellent people who have grown up immersed in the SHT world and reached very senior level. These people can be nurtured into ‘surprise allies’ by creating a shared emphasis on the areas of agreement and then working through how that alignment plays out in different spaces. For example, a CEO coming from a sales background might suddenly be a lot more interested in having meaningful, sustainable ‘outcomes’ and be encouraging C-level coordination. Or they might be suddenly a lot more interested in getting predictable results from IT projects so open to ‘exploratory phases’, strong iteration of outcomes and assumption-crushing.
• Act as the facilitator of this new approach. If you are somewhere at the top, or somewhere in the middle with some good people at the top, it’s possible to nurture the whole organisation in this direction. There is virtually never organised opposition, just momentum.
With all this as background, I have a few thoughts on the specific content of the article. As always, I find myself 90% aligned with you but then naturally spend more time on the 10% of nuance than the agreed-90%.
• I am a strong supporter of separating management / facilitator and technical-expert responsibility
• I generally like to seperate Functional and People responsibilities in a Change/ Development / “Project” context, but less so in a BAU context.
• In practice this means that I distinguish between Project/Product owners (responsible for project/product outcomes) and People managers responsible for all the things you mention, but also “owning” a team of people as “resources” to be applied to specific areas of work. In this world, people managers are constantly aware of how much each person is working on each ‘project’ and what their pipeline looks like in the future. When new priorities come in, the people manager is responsible for presenting options of how they may be resourced and then, together with the Project/Product managers, the potential impact on other deliverables. In this way the distinction is not precisely “content” v “personal” but “project” v “ resource”.
• As a corollary, prioritisation happens between “projects”: one or more stakeholders are presented with one or more options for what value would be expected when under different resourcing scenarios. The PMs determine the impact on the deliverables of resourcing decisions. The People-managers determine the options of project resourcing.
• Personally I don’t have experience of moving prioritisation to the team level and it’s not something that really attracts me. I trusty a team to work out how best to achieve a specific goal, but not how best to prioritise that goal against others or to work out when the goal is no longer worth pursuing. I would prefer to leave those difficult tasks to people with the overview and bandwidth to deal with them. If there are issues of “pointy-hired managers micro-managing, this seems more like an individual issue rather than a systems one. Poor people can have negative influences wherever they are so I’d be hesitant to respond by moving authority based on that.
Good article Daniel. I like it and would like to challenge you on a few thoughts.
1. Hierarchical reporting structure.
You actually describe alternatives for people management in your article which sort of undermines your assertion. I think hierarchies are natural in society. Native tribes have hierarchies, open source software has a hierarchy of contributors. There is also plenty of research and evidence that tribal and supportive hierarchies are good for people.
3. Projects are the means of doing work.
and
4. Project-based funding.
Not sure what your problem with Projects is. I realise there is a discussion about Project to Product in the digital domain, and you can throw in a discussion around Operational Process as well. There are a lot of organisational problems with funding models but my assertion would be that project funding done right is actually pretty good.
7. Categorical organisation of strategy.
I'm fascinated to hear what you write about this. My mind is turning cartwheels just thinking about the term.
Thanks Daniel, great article and thanks also for poking me. It provokes a lot of thoughts which I struggle to disentangle. Apologies for the brain-dump.
In my mind I place Hierarchy in my unholy trinity of Silos, Hierarchy and Targets, complete with delightful acronym, as a self-consistent mindset and approach. I find it useful to describe how these elements fit together, skim over the all-too-well know problems with this approach, sketch out the fundamentals of an alternative and then consider how you can change from one to another.
The SHT model
In the SHT model, it is a disappointingly small oversimplification to say that a wise and benevolent CEO starts with a target for the company and divides that into operate targets for functional leaders. For core business functions these are often targets - sales, margin, volume etc. These targets are then split recursively down a tree of mini-CEOs in which everybody is accountable for a neat, quantitive target that sums up linearly to those of the overall company. In this approach, communication and accountability are almost entirely vertical. Often in this model, the manger is also seen as the technical expert with people people promoted. Through the hierarchy through seniority of years or strong personal performance. There is little emphasis on management, strategy or system-building generally and people tend to view leaders as inherently more knowledgable than their teams.
Before skipping over the fairly obvious flaws with this approach, it’s important to recognise it’s strengths - some of which could be an article on their own:
• It is simple, familiar and fractal: Easy to understand, easy to reproduce, no need for any special consideration for anyone.
• It has clear accountability: Each person knows exactly what is expected of them and what resources are available to achieve it. Success of failure is on them.
• It ‘works’ in some contexts: In mature, static, BAU environments where work is individualistic due to well-defined specialised roles it can appear to work adequately. Most commonly ‘sales’ kinds of environments are natural fits, especially when there is the opportunity to factor in long-term customer relationships and satisfaction. However there are clear natural conflicts-of-interest even in these situations.
• It ‘works’ for many people. Many people are at work for the cash and are focussed on career advancement. Many people appreciate an organisational system that allows them to know exactly how they are measured and optimise their behaviour for that.
Of course the flips sides are also very clear:
• While it may be better in mature/BUA environments, this approach is a disaster in development or immature environments characterised by change and uncertainty. In these environment
• Due to it’s simplicity, familiarity and ‘obviousness’ the SHT approach is very often applied where it is grossly inappropriate especially when a former head of sales becomes CEO and generalises ‘what has always worked for them’, or when a company that is 90% applies standard approaches to the ‘change’ areas of the business, which are more and more critical to every company. [I view the fundamental differences between BAU and ‘Change’ work as a primary source of misunderstanding and alignment between departments and individuals]
• Holding people to account for targets is only as meaningful as the targets themselves. Even at the highest level, there are many ways to sacrifice the long term health of a company to spur short-term ‘improvements’ - shipping shoddy products, poor customer service, underinvesting in research and change, etc. It is extremely challenging to develop meaningful objective targets for individuals [and probably not worth the effort] but tightly holding people accountable to bad targets is essentially compelling people to do a bad job. “Optimising for the system” is a polite way of saying “gaming the system” and generally comes at the cost of the comp[any as a whole and/or its customers.
• In almost every area - some more obviously than others - true sustained ‘company success’ is the result of collaboration and alignment between individuals, departments and time-frames. It requires cross-objective prioritisation that adapts as knowledge is required. Precise, individual targets are almost always a focussed drive to the wrong destination.
The COM model (Collaboration, Outcomes, Measurement)
I won’t spend much time describing this as I think the general outlines are very familiar.
• Emphasise horizontal relationships and alignment (Collaboration). At each level, how do we work together to get where we want to go?
• Focus on Outcomes (not activities, not targets). What really matters? Spend time understanding the difference between the goal you are trying to achieve and the symptoms/measures of how to know if you are achieving it.
• Measure what you are doing and incorporate feedback loops. Uncertainty is real, so mitigate it. Don’t build business cases that assert a lot of unknowable things and trigger projects that can never be cancelled because someone would look bad. Measure the achievement to determine the viability of the ideas, not the people. Measure the symptoms of success but don’t go out and generate those symptoms as a substitute for achieving what you really want to. Tying someone’s hand to a board is not a cure for Parkinsons.
In a COM system, as managers/leaders get more senior they are progressively less required for their technical knowledge or ability to act on the ‘front line’. Rather they should show genuine expertise and passion as system-builders responsible for nurturing a bunch of people and ideas into a productive and sustainable whole.
SHT is essential individualistic, based on personal goals, vertical interactions and pseudo-objective personal accountability.
COM is essentially collective, based on shared goals, horizontal interactions and openly-subjective personal accountability.
How can you change from SHT to COM?
• Acknowledge that different working approaches can be appropriate in different areas.
• Look for alignment of very obvious principles (bottom line > top line, sustainable success etc.)
• Identify and convert natural ‘hidden’ allies. There are often some excellent people who have grown up immersed in the SHT world and reached very senior level. These people can be nurtured into ‘surprise allies’ by creating a shared emphasis on the areas of agreement and then working through how that alignment plays out in different spaces. For example, a CEO coming from a sales background might suddenly be a lot more interested in having meaningful, sustainable ‘outcomes’ and be encouraging C-level coordination. Or they might be suddenly a lot more interested in getting predictable results from IT projects so open to ‘exploratory phases’, strong iteration of outcomes and assumption-crushing.
• Act as the facilitator of this new approach. If you are somewhere at the top, or somewhere in the middle with some good people at the top, it’s possible to nurture the whole organisation in this direction. There is virtually never organised opposition, just momentum.
With all this as background, I have a few thoughts on the specific content of the article. As always, I find myself 90% aligned with you but then naturally spend more time on the 10% of nuance than the agreed-90%.
• I am a strong supporter of separating management / facilitator and technical-expert responsibility
• I generally like to seperate Functional and People responsibilities in a Change/ Development / “Project” context, but less so in a BAU context.
• In practice this means that I distinguish between Project/Product owners (responsible for project/product outcomes) and People managers responsible for all the things you mention, but also “owning” a team of people as “resources” to be applied to specific areas of work. In this world, people managers are constantly aware of how much each person is working on each ‘project’ and what their pipeline looks like in the future. When new priorities come in, the people manager is responsible for presenting options of how they may be resourced and then, together with the Project/Product managers, the potential impact on other deliverables. In this way the distinction is not precisely “content” v “personal” but “project” v “ resource”.
• As a corollary, prioritisation happens between “projects”: one or more stakeholders are presented with one or more options for what value would be expected when under different resourcing scenarios. The PMs determine the impact on the deliverables of resourcing decisions. The People-managers determine the options of project resourcing.
• Personally I don’t have experience of moving prioritisation to the team level and it’s not something that really attracts me. I trusty a team to work out how best to achieve a specific goal, but not how best to prioritise that goal against others or to work out when the goal is no longer worth pursuing. I would prefer to leave those difficult tasks to people with the overview and bandwidth to deal with them. If there are issues of “pointy-hired managers micro-managing, this seems more like an individual issue rather than a systems one. Poor people can have negative influences wherever they are so I’d be hesitant to respond by moving authority based on that.