The worst of both worlds
After a couple of longer posts with the two-part series of how product development benefits from flow (part 1 and part 2), I think today will be short and sweet (although, to be honest, I can't quite be fully sure before I get on to it, writing… That's how it works with me). I just thought of sharing this insight that came up the other day. I was talking to an engineering manager about challenges to deliver a complex program involving way too many teams.
As you would typically expect, and many often would have warned upfront, the specific case turned out to be a massive uphill battle. It would, likely in any case, just by the challenge itself, whenever we are making quite some changes to how things work, in the specific case coupled to a physical change that imposes a fixed schedule, and all of the implications from that. But often some of it is arguably self-inflicted as well. In the sense that things could have been set up differently, and with that higher chances to be set for success.
While I can't open up details, I can speak about some of underlying observations that give insight on why it has been a bigger undertake that it could have been (if set up differently):
Coupling of too many goals that had to be accomplished in parallel. I don't know for sure if the original research is from herself, but Johanna Rothman is a great reference on the theme. It has been empirically shown that whenever you couple more than two goals (or drivers), there's an exponential chance of failure.
Changes in architectural patterns and interfaces between components that tend to favor certain ways of working, but not necessarily changing enough of the "social circuitry" (to use the great analogy by Gene Kim and Steven Spear in their recent "Wiring the Winning Organization).
And the implication, or how at least the both of us that were having the chat could best articulate it, being that in some meaningful respect you ended up in the "worst of both worlds" (to contrast the more known positive version of "best of both worlds"). The additional challenge is that the real solution would probably be to slow things down, make sure the required foundations and engineering rigor is in place, perhaps rethink the approach in terms of goals/drivers coupling, but you know how it goes… it's now "crunch time", all hands on deck to get it out of the window before the upfront defined deadline that was also tied to a whole physical change. Again, "worst of both worlds" sounds about right.
Source: https://imgflip.com/memegenerator/22785497/Pinky-and-the-brain
By Rodrigo Sperb, feel free to connect, I'm happy to engage and interact. If I can be of further utility to you or your organization in getting better at working with product development, I am available for part-time advisory, consulting or contract-based engagements.