In software product development, we have idealized ways of working firmly planted in mission command, independent teams, etc. But we don't have an established vocabulary for when things "go wrong" (unless they go very wrong).
“No one trusts each other. Everyone is pointing fingers and gaming metrics to stay under the radar.” Am I wrong in thinking that this sounds like the (rather hellish) result of bad leadership higher up leading with fear rather than trust? I do think that this piece raises a number of interesting questions which go to an epistemic and fundamental issue right now: what is the relationship between business and humanity? Looking forward to part 3!
I'm not sure. I'm coming to the opinion that placing the blame on bad leadership, is the same kind of thinking that has leadership imagining bad individuals.
Thanks for sharing your thinking around this. Regarding differences between software development and manufacturing, I feel like another important one is the overwhelming possibility of the former. In software you can build pretty much anything, if you decide it’s worth expending the time and effort. Look too deep into the abyss of this type of unconstrained thinking, and you might go a little mad. But this kind of thing is much less likely when your thinking is constrained by standing in front of a big physical production line (which ties back into your point on visibility).
While not 1:1, the last point on empowered groups reminds me of putting together a task force, which is something I've seen happen as a sort of parallel stream ("Let's put everyone that's relevant in a room, align, and then unblock them"). This is something I've seen can be successful but it's interesting how, in a way, it's already a mechanism to circumvent the more idealised system, which in a way seems to be at least unconsciously admitting some scenarios where the idealised system may falter.
"...we lag far behind most other technical business domains in terms of a sophisticated conversation about human factors and humanity in the production chain". I'm (re) minded of the base book in my go to list, which is "The Goal". Follow this up with things like "Phoenix Project" and you can't help thinking, "Errr, why aren't we doing that?". Then, as you say, one looks across to "operations" as we know them in my org, and see they're all over "Jidoka" and have "stop the line" and continuous improvement techniques built in to normality... "Errr, why aren't we doing this? Perhaps I can find a way to (redactions possibly needed) share a thread I ran for a few weeks internally based on this. SIGH, SIGH, and SIGH ONCE MORE
I'm not certain about all the introduction, but for sure, the last part is basically what I'm fighting for: presume some things will fail, or unexpected, or new things will come up and disrupt the current work. Right now, the main delusion I see with most software projects is the idea that you can predict that, you can plan for it, you can anticipate the risk. It leads for abuse on both side: a lot of efforts is put on being resilient to things that are unlikely to happen, and a lot of deny is done on things that can happen but are out of our control. So, you get this alpha period pre-release where people put a sign "here is where we kill all the dragons that we breed during the last months", like if we know how many dragons would be and how hard it will be to kill them. You also get this gigantic and costly infrastructure able to scale to millions and reach 6 9 availability, for a product that hasn't found its market for yet, and still depends entirely on a single external SaaS with no minimal SLA, that no one will know how to replace if the provider goes the way of the Dodo.
I believe iterative development,
software development agility, continuous delivery, and many other improvements in the last 50y have been around that, but mostly focus on a single team, highly integrated, highly vertical. Where we are still need to do some work on is how to scale this, in revenue, in complexity, in people. Most of the tools I've seen trying to address those seem to be part of two different camp: either they imitated the small scale solution but on a larger scale, or they try to adapt the last century's large scale solution to the newer trends. The exception to this IMO is Wardley Mapping and somewhat Team Topologies. Both try to create a flexible and yet manageable and actionable view of the largest picture on their own domain, but I don't we have yet totally master this.
“No one trusts each other. Everyone is pointing fingers and gaming metrics to stay under the radar.” Am I wrong in thinking that this sounds like the (rather hellish) result of bad leadership higher up leading with fear rather than trust? I do think that this piece raises a number of interesting questions which go to an epistemic and fundamental issue right now: what is the relationship between business and humanity? Looking forward to part 3!
I'm not sure. I'm coming to the opinion that placing the blame on bad leadership, is the same kind of thinking that has leadership imagining bad individuals.
Thanks for sharing your thinking around this. Regarding differences between software development and manufacturing, I feel like another important one is the overwhelming possibility of the former. In software you can build pretty much anything, if you decide it’s worth expending the time and effort. Look too deep into the abyss of this type of unconstrained thinking, and you might go a little mad. But this kind of thing is much less likely when your thinking is constrained by standing in front of a big physical production line (which ties back into your point on visibility).
While not 1:1, the last point on empowered groups reminds me of putting together a task force, which is something I've seen happen as a sort of parallel stream ("Let's put everyone that's relevant in a room, align, and then unblock them"). This is something I've seen can be successful but it's interesting how, in a way, it's already a mechanism to circumvent the more idealised system, which in a way seems to be at least unconsciously admitting some scenarios where the idealised system may falter.
"...we lag far behind most other technical business domains in terms of a sophisticated conversation about human factors and humanity in the production chain". I'm (re) minded of the base book in my go to list, which is "The Goal". Follow this up with things like "Phoenix Project" and you can't help thinking, "Errr, why aren't we doing that?". Then, as you say, one looks across to "operations" as we know them in my org, and see they're all over "Jidoka" and have "stop the line" and continuous improvement techniques built in to normality... "Errr, why aren't we doing this? Perhaps I can find a way to (redactions possibly needed) share a thread I ran for a few weeks internally based on this. SIGH, SIGH, and SIGH ONCE MORE
I'm not certain about all the introduction, but for sure, the last part is basically what I'm fighting for: presume some things will fail, or unexpected, or new things will come up and disrupt the current work. Right now, the main delusion I see with most software projects is the idea that you can predict that, you can plan for it, you can anticipate the risk. It leads for abuse on both side: a lot of efforts is put on being resilient to things that are unlikely to happen, and a lot of deny is done on things that can happen but are out of our control. So, you get this alpha period pre-release where people put a sign "here is where we kill all the dragons that we breed during the last months", like if we know how many dragons would be and how hard it will be to kill them. You also get this gigantic and costly infrastructure able to scale to millions and reach 6 9 availability, for a product that hasn't found its market for yet, and still depends entirely on a single external SaaS with no minimal SLA, that no one will know how to replace if the provider goes the way of the Dodo.
I believe iterative development,
software development agility, continuous delivery, and many other improvements in the last 50y have been around that, but mostly focus on a single team, highly integrated, highly vertical. Where we are still need to do some work on is how to scale this, in revenue, in complexity, in people. Most of the tools I've seen trying to address those seem to be part of two different camp: either they imitated the small scale solution but on a larger scale, or they try to adapt the last century's large scale solution to the newer trends. The exception to this IMO is Wardley Mapping and somewhat Team Topologies. Both try to create a flexible and yet manageable and actionable view of the largest picture on their own domain, but I don't we have yet totally master this.
Love this one. Fruitful paths to explore.