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.
for 1. my assertion on each of these is not that are always destructive - each serves a purpose and as such my examples are simply real life experiences where we started to break the assumptions associated. There are assumptions about people management which go hand in hand with the hierarchy - I could probably do a better job explaining that so I will improve that on the next edit - cheers!
For 3 and 4. I don't have a problem with projects :) - the world gets a lot of things done using them :) There are also scenarios where using this approach may introduce incentives or introduce other forms of friction which may interfere with the value you are striving for by using a Project construct or Project Funding so in those circumstances it maybe worth exploring approaching differently.
For instance, investment which adds a service to an organisation that it has now committed to for the long term might benefit in using an alternative funding strategy. In accounting those mechanisms exist (adding the costs to the cost base) but often project funding is applied as the default. The alternative to project structures you see quite commonly in SaaS businesses - domain structures for teams with cadences of outcome oriented goal setting and KPIs and frequent delivery and frequent feedback loops. The fact that its the default and the friction to do it differently when that maybe necessary and the best path for the organisation, yet is astronomically higher due to inertia to changing what are perceived as the norms.
Thank you again Martin for your feedback - very helpful - I do go back and edit my posts periodically so that they become more useful references over time.
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.
A lot of discussion of working practices tend to describe what is already there as completely flawed and unworkable.
Nothing is so black and white. Why things are the way they are can be for many reasons. Telling someone something flat out doesn't work isn't credible when they feel they have had success so acknowledging what is there and what it achieves and where it may present challenges is a better foundation for building trust and making adjustments.
The example.I provided is one from Seek Asia to show there are alternatives but I agree they are not a universal approach. The context is critical for helping inform which approach might be appropriate.
For directional decisions I don't necessarily mean that it's solely to the team. The majority of posts on this publication describe a two way interaction with leadership. What is different is this doesn't necessarily travel down the reporting line. Again, like Seek Asia, leaders aligned on some direction expressed through a collection of.measurable goals. The teams proposed goals aligned to these that they would focus on and each would adjust based on feedback - a human form of eventual consistency 😀
I am not suggesting the abdication of leadership, providing context and decisions across contexts wider than the team are critical leadership responsibilities as you say. My point in this real ife example, is just that leadership need not always be restricted to just the functional reporting line manager. This is not a universal issue but it is a common issue when there are a software development managers who have spent years project managing a team and are shifting to more empowering model for the team. The example hopefully shows there are situations where challenging the assumption and making a change was valuable.
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.
Hi Martin, fair feedback -
for 1. my assertion on each of these is not that are always destructive - each serves a purpose and as such my examples are simply real life experiences where we started to break the assumptions associated. There are assumptions about people management which go hand in hand with the hierarchy - I could probably do a better job explaining that so I will improve that on the next edit - cheers!
For 3 and 4. I don't have a problem with projects :) - the world gets a lot of things done using them :) There are also scenarios where using this approach may introduce incentives or introduce other forms of friction which may interfere with the value you are striving for by using a Project construct or Project Funding so in those circumstances it maybe worth exploring approaching differently.
For instance, investment which adds a service to an organisation that it has now committed to for the long term might benefit in using an alternative funding strategy. In accounting those mechanisms exist (adding the costs to the cost base) but often project funding is applied as the default. The alternative to project structures you see quite commonly in SaaS businesses - domain structures for teams with cadences of outcome oriented goal setting and KPIs and frequent delivery and frequent feedback loops. The fact that its the default and the friction to do it differently when that maybe necessary and the best path for the organisation, yet is astronomically higher due to inertia to changing what are perceived as the norms.
For 7. Fortunately I've written about this one before so you can read my older post whilst waiting for my next couple of posts that elaborate on the next 6 unchallenged assumptions (already written - will post at least one of them next week): https://open.substack.com/pub/wioota/p/strategic-pillars-are-a-goal-setting?r=6qaf&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true
Thank you again Martin for your feedback - very helpful - I do go back and edit my posts periodically so that they become more useful references over time.
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.
Thanks Roger, I like the approach you describe.
A lot of discussion of working practices tend to describe what is already there as completely flawed and unworkable.
Nothing is so black and white. Why things are the way they are can be for many reasons. Telling someone something flat out doesn't work isn't credible when they feel they have had success so acknowledging what is there and what it achieves and where it may present challenges is a better foundation for building trust and making adjustments.
The example.I provided is one from Seek Asia to show there are alternatives but I agree they are not a universal approach. The context is critical for helping inform which approach might be appropriate.
For directional decisions I don't necessarily mean that it's solely to the team. The majority of posts on this publication describe a two way interaction with leadership. What is different is this doesn't necessarily travel down the reporting line. Again, like Seek Asia, leaders aligned on some direction expressed through a collection of.measurable goals. The teams proposed goals aligned to these that they would focus on and each would adjust based on feedback - a human form of eventual consistency 😀
I am not suggesting the abdication of leadership, providing context and decisions across contexts wider than the team are critical leadership responsibilities as you say. My point in this real ife example, is just that leadership need not always be restricted to just the functional reporting line manager. This is not a universal issue but it is a common issue when there are a software development managers who have spent years project managing a team and are shifting to more empowering model for the team. The example hopefully shows there are situations where challenging the assumption and making a change was valuable.