Over the years, I have observed many instances of this situation: There is a general agreement about what great looks like. There is disagreement about the "root cause" or "problem definition." The team gets bogged down in analysis paralysis and political maneuvering or has a string of failed efforts to "fix" the problem and loses confidence. What's going on in some cases?
While I have, for the last decade, attempted to bring Product Mgmt thinking to running infrastructure teams, I have only recently moved full time into the Product Mgmt practice.
The idea of "root cause" being too difficult - or even impossible - to find resonates deeply with me. My infrastructure teams and dev teams will attempt to find root cause, but don't chase it. Instead a wise old engineer said to me, "Boyd, let's find contributing factors and pick the most important ones to address." Ultimately this lea, in my last job, to just over a year without a SEV1 incident.
We - grumpy old engineering and I - asked ourselves, "What could we do with process evolution? Wouldn't working contributing factors to process-breakdown just be what all the cool kids call 'continuous improvement?'"
So we hit upon just putting some overly simple process in place and providing the team with a weekly way to talk about managing that process. Over time we ended up with a Confluence space of wickedly effective processes owned by the engineers for the benefit of business outcomes. None of them were perfect because ... well ... humans. But all of them were _manageable_. My engineers regularly asked for new or longer meetings, killed meetings we didn't need and reporting a high sense of ownership in team outcomes.
Simple example - Grumpy Engineer says in 1:1, "Let's change standup. Let's not go from person to person in the usual way. Lets instead go ticket by ticket on the Kanban board from right to left." I replied, "Seems trivial why bother?" He replies, "Because we talk about the work not the person." He took this to the team meeting and the team said - after some discussion and FUD, "Let's do it for 2 weeks and see what happens."
Within a week WIP decreased, deployments increased and folks were openly talking about how they felt better informed and better able to help out on the things that mattered. We never went back, though we did change things about the board, prioritizing review and deployment of work over starting and doing work, etc.
I hope this is an example of the spirit of the post or that someone will set me straight. Thanks for the inspiration regardless.
An issue I have with this discourse is that the people who have to solve the mess of complex problems usually don't get a say about their feelings and stake in it. They usually lack the power to negotiate much less to influence and control the way it relates to their professional identity. The corporate world is still very much an inequitable space where powerplay still ranks supreme, top-down. In so doing are we overthinking the complicated and complex?
"Gap Thinking" isn't inherently bad - the answer to "where are we? where do we want to be? how do we get there?" is the basis of every strategy. The problem, as correctly identified, is when selecting the path of "how do we get there".
Complicated problems benefit from a methodical deconstruction and reduction approach. Complex problems benefit from exploratory and adaptive methods, the 'levers' referred to. This has been described by HBR as "Adaptive Versus Technical Change" in this classic article: https://hbr.org/2002/06/a-survival-guide-for-leaders
The problem is that traditional management and problem solving techniques often only focus on the technical side, for all the reasons mentioned (easy to explain, alluring to think about in that way). However, we can apply "gap thinking" to complex problems just as much. In fact, that's part of the modern product & solution discovery process.
You’re getting shared in a complexity community, John!
In case you haven’t seen it, I did a write up of the Estuarine Framework, which is very much “get everyone’s pet ideas up on a wall while focusing on a slightly different level of granularity that precludes the Gap”
(Which is also to say that I love this article - especially the breakdown of what a gap vs complexity approach looks like in a specific familiar situation. I’ve definitely made the “tell how” mistake before.)
Love this. The intersection of people, managers, and business needs make for my favourite kinds of problems. Org Dev has so many opportunities to make bets & experiment using psychology and sociology as guides. I'm trying to get better with numbers so that I can bring more complexity theory into my work, at what scale can complex problems where individual agency become predictable (ie Brownian Motion)? And how do you design for that macro thinking, whilst creating personalised micro solutions for specific audiences? It makes my brain happy. Thanks for adding your thoughts to this :)
While I have, for the last decade, attempted to bring Product Mgmt thinking to running infrastructure teams, I have only recently moved full time into the Product Mgmt practice.
The idea of "root cause" being too difficult - or even impossible - to find resonates deeply with me. My infrastructure teams and dev teams will attempt to find root cause, but don't chase it. Instead a wise old engineer said to me, "Boyd, let's find contributing factors and pick the most important ones to address." Ultimately this lea, in my last job, to just over a year without a SEV1 incident.
We - grumpy old engineering and I - asked ourselves, "What could we do with process evolution? Wouldn't working contributing factors to process-breakdown just be what all the cool kids call 'continuous improvement?'"
So we hit upon just putting some overly simple process in place and providing the team with a weekly way to talk about managing that process. Over time we ended up with a Confluence space of wickedly effective processes owned by the engineers for the benefit of business outcomes. None of them were perfect because ... well ... humans. But all of them were _manageable_. My engineers regularly asked for new or longer meetings, killed meetings we didn't need and reporting a high sense of ownership in team outcomes.
Simple example - Grumpy Engineer says in 1:1, "Let's change standup. Let's not go from person to person in the usual way. Lets instead go ticket by ticket on the Kanban board from right to left." I replied, "Seems trivial why bother?" He replies, "Because we talk about the work not the person." He took this to the team meeting and the team said - after some discussion and FUD, "Let's do it for 2 weeks and see what happens."
Within a week WIP decreased, deployments increased and folks were openly talking about how they felt better informed and better able to help out on the things that mattered. We never went back, though we did change things about the board, prioritizing review and deployment of work over starting and doing work, etc.
I hope this is an example of the spirit of the post or that someone will set me straight. Thanks for the inspiration regardless.
An issue I have with this discourse is that the people who have to solve the mess of complex problems usually don't get a say about their feelings and stake in it. They usually lack the power to negotiate much less to influence and control the way it relates to their professional identity. The corporate world is still very much an inequitable space where powerplay still ranks supreme, top-down. In so doing are we overthinking the complicated and complex?
That was cool and I liked this so much. Well, you must also try the top class https://sparkspeechtherapytampa.com website.
Guilty in Gap thinking, will try to improve. Thanks
"Gap Thinking" isn't inherently bad - the answer to "where are we? where do we want to be? how do we get there?" is the basis of every strategy. The problem, as correctly identified, is when selecting the path of "how do we get there".
Complicated problems benefit from a methodical deconstruction and reduction approach. Complex problems benefit from exploratory and adaptive methods, the 'levers' referred to. This has been described by HBR as "Adaptive Versus Technical Change" in this classic article: https://hbr.org/2002/06/a-survival-guide-for-leaders
The problem is that traditional management and problem solving techniques often only focus on the technical side, for all the reasons mentioned (easy to explain, alluring to think about in that way). However, we can apply "gap thinking" to complex problems just as much. In fact, that's part of the modern product & solution discovery process.
You’re getting shared in a complexity community, John!
In case you haven’t seen it, I did a write up of the Estuarine Framework, which is very much “get everyone’s pet ideas up on a wall while focusing on a slightly different level of granularity that precludes the Gap”
https://tomkerwin.substack.com/p/a-trip-into-the-estuary
(Which is also to say that I love this article - especially the breakdown of what a gap vs complexity approach looks like in a specific familiar situation. I’ve definitely made the “tell how” mistake before.)
Love this. The intersection of people, managers, and business needs make for my favourite kinds of problems. Org Dev has so many opportunities to make bets & experiment using psychology and sociology as guides. I'm trying to get better with numbers so that I can bring more complexity theory into my work, at what scale can complex problems where individual agency become predictable (ie Brownian Motion)? And how do you design for that macro thinking, whilst creating personalised micro solutions for specific audiences? It makes my brain happy. Thanks for adding your thoughts to this :)
I always love the way you keeps reminding us that people, humans, is always a part of the equation
That's what make it difficult but also exciting!
Our humanity is a beast to be tamed but also unleashed